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ABSTRACT 



A computerized system and method for managing work 
in process is provided. An initial transaction records 
case specific information. The case specific information 
is automatically linked with a work source index which 
includes basic client information. An electronic file is 
created for each case arising out of the initial transac- 
tion record. As work is performed on the case, the 
system tracks its progress and providces a variety of 
support functions. An electronic activity log function 
maintains a record of key activities involved in the 
processing of work items. An electronic diary function 
provides a means for prioritizing work and for schedul- 
ing various tasks. A staff table function provides a facil- 
ity for storing information relevant to office personnel. 
Most of the system functions are integrated with the 
staff table function which provides a number of security 
and function parameters. A text processing function is 
provided which integrates stored database information 
into Preformatted and customized documents. A "local 
data" function provides a facility for customization of 
data recordation and output at the local level. Various 
other systems functions provide the ability to modify, 
update, search and record additional case information. 
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H. CLAIMS 

A. FIELD OF THE INVENTION 
This invention relates to computer systems and meth- 
ods, and more particularly to such systems and methods 
for work management and the like. 

B. BACKGROUND OF THE INVENTION 



the notice to that handler and calculates and notes the 
specific reserves to be set aside for the claim. 

The original notice is given to a clerk for manual 
issuance of a claim number from a Register Book and 

5 for input into FOCS. (FOCS is a computer based claim 
recording system which relies on a mainframe com- 
puter located at a remote location to record the notice 
of loss. The FOCS system is used to record only actual 
claims and to issue certain payments. No claim adjust- 

10 ment support is provided to assist a claim handler in the 
progress of a claim to conclusion. The purpose of 
FOCS is essentially to assist in the maintainenance of 
corporate financial records.) After the notice of loss 
information has been input into FOCS, a file is prepared 

15 and filed. 

On a daily basis, clerks search all "open" files for 
claims with a diary date matching the day's date (See 
FIG. 2). All applicable files are removed and given to 
the appropriate claim handler or supervisor. After the 
20 necessary action is taken the files are refiled and any 
. new diary dates noted. 

When a claimant or insured calls to check on the 
status of a claim the handler, supervisor or clerk must 
again retrieve the file from wherever it is filed (See 
25 FIG. 3). The file is reviewed as necessary and then left 
for a clerk for refiling. At any time while the file is not 
properly filed, no correspondence received or other 
document can be placed in the file without undertaking 
a search for the file. 
30 During the time the claim is "open", key events must 
be recorded in an Activity Log to provide an audit trail. 
(The Activity Log is one or more preprinted sheets of 
paper which are affixed to the inside of the claim file.) 
As these key activities occur, the claim handler is obli- 
35 gated to record them in the Activity Log. If the file is 
not located immediately, it becomes likely that the key 
event(s) will be recorded inaccurately or not at all. 

When work on the claim has been completed, the 
handler requests that the file be closed. (See FIG. 4). A 
40 closure statement is input into the FOCS system to 
update the corporate record and the file is stamped 
closed and filed in a "closed" file bank. After a specific 
retention period all files are put in dead storage and then 
eventually destroyed. 



As can be clearly seen, the prior art claim processing 
The processing and tracking of work in process in system, like most work processing systems, requires that 
most environments is virtually non-existent or intensely the file be available for virtually every activity. Thus, 
manual. By way of example, the processing and track- when files are not found in their normal location, prob- 
ing of damage loss claims has been a time-consuming, lems arise. Still further, recording of specific key events 
mostly manual process requiring multitudes of paper 50 in the Activity Log and the maintenance of diary dates 
records. As such, claim processing and tracking is ex- depends on human diligence. As such, many things 
pensive, complex and relatively unreliable in maintain- which should be done or recorded never get completed 
ing the collected information. in a timely manner. 

In a typical prior art claim processing system, a nRTFrT<5 OF THF TNVFNTION 

claims office receives an initial notice of a loss from an 55 ^ OBJECTS OF THE INVENl ION 

insured, a claimant, a customer or an agent. The loss Accordingly it is an object of the present invention to 

notification is received by mail, telephone, or in-person. provide a system and method for alleviating the forego- 



By way of example, when a notice of loss is received by 
mail in the claims office, it is sorted into the appropriate 
line of insurance business (e.g. workers' compensation, 
automobile, property/liability, fidelity/surety etc.)(See 
FIG. 1). Loss notices are then delivered to one or more 
assistant managers and/or unit supervisors who review 
the notices and determine which claim "handler" actu- 
ally will work on the claim(s). The supervisor also de- 65 work processing, 
termines a diary date which is recorded on the original It is yet another object to minimize the 
file to check on the status of the claim and the assigned pare and complete forms, letters, reports ai 
handler's progress. The supervisor then sends a copy of processing work. 



ing problems and improving upon the prior systems and 
methods. 

It is another object of the present invention to reduce 
the time to respond to telephone inquiries about work in 
process. 

It is a further object to automatically and securely 
maintain a record of the activities of staff members in 
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It is a still further object to reduce paper intensity in by interfacing with the Host and its databases, depend- 

the maintenance of records in processing work. ing on where the policy information resides. This infor- 

T, ,r ^t- -,-T TXT, ,r^xT-r,^x, matioD "prefills" certain fields in the LPT thereby mini- 

D. SUMMARY OF THE INVENTION sizing operator input. 

In accordance with the present invention, there is 5 Once the information requested in the LPT is input, 

provided a system and method for substantially auto- and stored in a local database, the transaction is nor- 

mating work management. To illustrate the capabilities mally "routed", by the input operator, to a supervisor to 

of this system and method, reference is made to the access and review the file ("routing" generates a brief 

processing of claims. This reference should not be con- message to another staff member's "mailbox"). When a 

strued as a limitation on the application of this system to 10 claim is routed to a supervisor, the message generated to 

other work environments. the supervisor's "mailbox" (discussed in detail below) is 

In one preferred embodiment of the present invention a brief summary of the claim transaction. After review- 
supervisors and other staff members are provided with ing the claim, the supervisor electronically assigns it to 
the ability to maintain an accurate record of all activi- a particular staff member, sets at least one due date 
ties undertaken in the processing of a claim and the 15 ("diary" date) for review of the progress of the claim 
further ability to quickly and easily access the complete and sets aside reserves (based on his experience and 
claim file at any time. In practice, the processing of a calculations) to cover the expected cost of the claim, 
claim begins with the receipt of a notice of a loss from The electronic assignment transmits a claim summary 
an insured, a claimant, a customer or an agent. These message to the assigned handler's "mailbox" in the same 
loss notices are received by mail, telephone, in person 20 way the claim was originally "routed" to the supervi- 
or electronically. The information from these notices is . sor. 

keyed into a local computer where a separate electronic When the claim is assigned and routed to a claim 

file or record is created for each loss. (When the notice handler, an automatic numbering facility assigns the 

is transmitted to a claim office electronically it is put in next available, appropriate number(s) to the claim(s). 

the form of information which can be used to prefill 25 This facility eliminates the extra, manual step of ascer- 

fields in an Initial Input or Loss Processing transaction. taining the next unused number(s) and recording it on 

This greatly cuts down on input time.) the claim file and elsewhere. 

In a preferred embodiment of the present system and The assignment of diary dates for the supervisor is 

method, an operator accesses the local computer done either manually or automatically. Automatic dates 

through a terminal where he requests (usually through 30 are calculated and set by the system based on the type of 

a displayed menu) a series of input screens called the claim and the handler's experience. Manual dates are set 

Loss Processing Transaction ("LPT"). These screens, to override or augment the automatic dates set by the 

which comprise the LPT, each have a number of empty system. Dates also may be set in the "diary" by the 

fields preceded by descriptive prompts. Information is claim handler or any odier staff member with appropri- 

input into the local computer, in accordance with the 35 ate authority. 

descriptive prompt, from the notice of loss. A separate Individual claim files are accessible directly by select- 
series of LPT screens is available for each line of insur- ing a particular diary entry. When the claim is accessed 
ance business (e.g. workmen's compensation, automo- from the diary in this manner an "Activity Log" associ- 
bile, property/liability, fidelity/surety, etc.). Thus, the ated with the particular claim is displayed. This permits 
particular LPT screens which are displayed to the input 40 the handler or supervisor to find out the most recent 
operator are formatted according to the particular line activity undertaken or to see particular instructions 
of business which is the subject of the claim. which should be followed. If a diary entry is not ac- 
The LPT is designed to capture information relevant cessed or "rediaried" as of its date, it will "rollover" to 
to claim recording and to the loss adjustment process. the succeeding day until it is accessed and rediaried. 
All data relating to a claim which is collected, is stored 45 This prevents dates from being missed due to an unex- 
in a locally supported database adapted to interface pected absence or illness. If a diary date rolls over too 
with a remotely located host computer ("Host") and its many times an "alert" message is generated to the han- 
databases. The Host computer preferably maintains dler's supervisor. 

policy information and other information, used in the The diary also acts as a work load monitor because 

loss adjustment process, that is also employed in the 50 the number of claims which should be "diaried" for any 

regular activities of the company. given day is limited. If a supervisor/manager attempts 

If, for example, the claim is related to an automobile, to set a diary date on a new claim for a particular han- 

a variety of relevant information is input from the no- dler when the diary listing for that handler already has 

tice of loss and other sources (e.g. the insured's policy, the maximum number of claims to be reviewed for that 

police reports, interviews, etc.), including; information 55 day, a message is displayed to the supervisor (Despite 

about the insured, information about the insured's pol- the message, the supervisor can still assign the diary 

icy, information regarding special procedures to be date, if he desires). In this way, work can be more effi- 

undertaken in the processing of the claim, a description ciently distributed throughout an office and one partic- 

of the accident, a description of any physical or prop- ular handler should not be overburdened, 

erty damage, information regarding any injured party, 60 When an LPT is used to input a notice for a new 
information about witnesses and/or passengers and any claim, an electronic Activity Log is automatically cre- 

other relevant comments. All this information need not ated along with the new claim file or at the time of the 
be input into the claim file created with the LPT imme- first activity. An Activity Log is essentially an over- 
diately; it may be added subsequently as more details view of key activities associated with the loss adjust- 

are uncovered during the investigation of the loss. 65 ment process (e.g. payments, interviews, correspon- 

Prior to inputting the notice of loss information, the dence, etc.). Comments are electronically entered into 
insured's policy information is verified by extracting the log to document these activities through normal 
such information from the local computer's databases or keyboard entry or automatically when a system driven 
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activity is undertaken. The date and the operator's ini- 
tials are automatically entered into the log with the 
entry. Entries into the log are readily accessible for 
review by an operator and are displayed in reverse 
chronological order so that the most recent entries 
appear first. 

Whenever certain functions within the system are 
accessed, and activities undertaken therefrom (e.g. text 
processing or payments), entries are automatically made 
to the Activity Log for that claim. The entries summa- 
rize the activity without conscious effort by the opera- 
tor. Each entry consists of the date, the operator, the 
activity and the specifics associated with that activity 
(e.g. check issued for $500.00 to John Doe, etc.). The 
extra steps which would be required to locate the log, 
recall the specifics of the activity, and make a manual 
entry are eliminated. A handler's memory is not in- 
volved at all and the log will thus be accurate and up-to- 
date. Still further, the log serves as an audit trail because 
the Activity Log entries, once made, are secure and 
cannot be changed. 

In a preferred embodiment of the present invention, 
text processing is also included within the system. This 
provides automatic/semi-automatic generation of forms 
and letters tailored to the particular office and the par- 
ticular claim. In practice, the text processing function is 
selected and a form or letter then chosen. Most of the 
pre-prepared forms and letters have blank fields embed- 
ded in them to make them specific to the appropriate 
claim. The system automatically attempts to fill in these 
blank fields from information previously entered and 
stored in the claim database. This saves time because the 
operator does not need to locate the basic claim infor- 
mation in a paper file or even key it in. If all the neces- 
sary information to complete the document is not avail- 
able from the claim file, the operator is prompted to 
provide it manually. When all the required fields in the 
document have been filled, the document's text data .is 
sent to a print queue where it is held until released to a 
printer. The documents are precoded to apprise the 
system and an output operator (an individual in charge 
of the printing of forms, letter and/or checks) of the 
proper paper on which the correspondence is to be 
printed and the number of copies to be generated. 

It is also preferred that an automatic payment func- 
tion be included in the system. There are typically four 
types of payments which can be made: closing pay- 
ments, repetitive payments, partial payments and reo- 
pen/close payments (these payment types will be dis- 
cussed in more detail in the Detailed Description). 
Checks may be automatically issued for any of the three 
types of payments upon selection by the claim handler. 
The empty fields on the various payment screens are 
prefiUed from information previously entered into the 
claim file (database). If insufficient information is avail- 
able in the claim file to print a check, the operator is 
prompted to manually input the missing information in 
the appropriate fields. 

If the requested amount of a check exceeds the spe- 
cific monetary authority of the jjerson authorizing the 
request the check request is automatically routed to a 
supervisor for approval. Thus, all checks which are 
finally printed have been duly authorized. 

There are two ways checks can be automatically 
issued. With the first method the check request is sent 
from the local computer to the Host computer where it 
is processed. The Host assigns a check number and 
sends a check printing command to a check printing 
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queue for printing on a check printer located in the 
local office. With this method the local system is only 
involved in the front end of the transaction. The rest of 
the check transaction is handled by the Host computer. 

5 With the second method the check request is pro- 
cessed by the local computer which debits the local 
office's account in real time. (With the first method the 
corporate account is debited off-hours after all checks 
have been issued for a given day). The assignment of 

10 check numbers occurs locally and the check printing 
command is issued by the local computer. The Host is 
typically apprised of the check transactions via batch 
uploading from the local computer at various intervals. 
As indicated above, all payments generate an entry to 

15 the Activity Log including: amount, requester, nature 
of benefit, payee name and check number. This happens 
automatically without any effort on the part of an oper- 

In a preferred embodiment of the present invention, 

20 an interactive Help system is available. The Help sys- 
. tem is generally invoked from any screen, during any 
operation of the system, throughout the processing of a 
claim. It is activated by actuating one or more "func- 
tion" keys at a terminal (i.e. separate keys which do not 

25 normally generate alphanumeric characters on the dis- 
play screen). The Help function initially displays trans- 
action and/or field specific codes which are used for 
filling in data fields within the various screens. Actuat- 
ing still other function keys provides an explanation as 

30 to how to select and move between modules and opera- 
tions within the system and accomplish various transac- 
tions or activities. The Help function is used to assist an 
operator in the proper input of information and the 
manipulation of screens "and functions. 

35 An "Info Search" feature, in a preferred embodiment 
of the invention, permits any operator to check on the 
status of a claim based on only minimal information, 
such as: the insured's last name, the claimant's last name, 
the insured's policy number or the claim number. 

40 (When a claim file is created this "minimal information" 
is automatically entered as a record into a separate Info 
Search file for this purpose.) This feature is particulariy 
valuable when an insured or a claimant telephones to 
check on the status of a claim. With the Info Search 

45 feature, it is not necessary to physically retrieve a paper 
file which may or may not be complete. Rather, the 
operator who receives the telephone call simply ac- 
cesses Info Search function and inputs the appropriate 
name (full name, partial name or phonetic equivalent) 

50 and/or number to locate the electronic Info Search 
record containing the "minimal information". If the 
caller needs more detailed information, the complete 
claim file may be accessed, including its up-to-date 
Activity Log. From this an operator can quickly and 

55 easily provide the caller with a complete status report. 
Correspondingly, with a minimum of effort, the Activ- 
ity Log may be updated to include any information 
imparted during the telephone call. 
Directory Tables, which are included in a preferred 

60 embodiment of the present invention, function, in part, 
as an online telephone/address book. Any name, tele- 
phone number, address and tax code may be keyboard 
entered and stored in the Directory Tables. These 
entries are then accessible by name and can include 

65 attorneys, claimants, doctors, state agencies, etc. The 
Directory Tables are not claim specific and are shared 
by the entire office. These tables are also integrated 
with other system functions (e.g. Text Processing, Pay- 
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ments, LPT, etc.) to prefill infonnation into their re- reports, forms, letters and checks to be printed. This is 
spective data fields, as necessary. helpful when a number of lengthy or specialized print 

A Staff Table function provides, online, a record for jobs have created a backlog at the time that a top prior- 
each member of the claim staff. Each record includes ity print job is sent to the printer. The print queue man- 
the current title, diary limit, authority level and supervi- 5 agers enable an output operator to shift the print jobs in 
sor of the staff member as well as the maximum case the print queue to accommodate those with higher pri- 
load of that member. The Staff Table function is inte- ority. The print queue managers also display any special 
grated with virtually every other system function. The printing information, such as number of copies, type of 
information contained in the various Staff Table records paper, etc. 

(referred to hereinafter as "the Staff Tables") is used to 10 a specialized feature, which is part of a preferred 
verify and prefill various data fields in other system embodiment of the present invention is referred to gen- 
functions. The authority level, diary limit and caseload grally as "local data." The local data feature includes a 
limits of each staff member are set by supervisors with screen or set of screens which have been generically 
appropriate authority and entered into the Staff Tables. formatted to accommodate database fields of numeric. 
These records can be modified, deleted or added as 15 j^te and alphanumeric data. (A set of these screens is 
necessary. available for input and display for each claim). The 

Statistics regarding claim assignments are stored and particular display configuration of the screen or screens 
monitored to determine individual and office-wide per- selectable by the individual claims office. The pur- 
formance through a caseload monitoring function. This ^^^^ jj^^l ^^ja feature is to permit each claims 

function allows a supervisor to assess the general nature 20 ^^^^^ ^^ ^jg^ ^^^^^ screens to accommodate 

ofan individual's work load and to examine a staff mem- specialized information which the office desires to 
ber's progress on groups of claims. This feature assists ^^intain. This information primarily is of the type 
the supervisors m assigning claims to particular han- ^^^^^^ complete specific state agency filing require- 
dlers and making more efficiem use of the staff ^^^^^^ ^ ^^^^ , statistical purposes 

A wmdowing function also is provided in a preferred 25 ^^^t^^e, ^^eds. The data input through the custom- 
embodiment of the present mvention. The wmdowmg .^^^ ^^^^^^^ ^^^^^^ ^.^^^ j^^^ ^^^^ ^^^^^.^^ i„. 
function permits an operator to work on more than one ^^^^^^ ^^^^^ ^^^^^ 

claim by opemng a wmdow into other claim files ^^^^^^^^^^^ ^^e Host, 
while still others are being processed. (The operator can ^ r j v j- r.u 

only enter data into one claim file at a time, but can 30 I" ^ 1'^^%'^^ embodiment of the present invention 
switch back and forth between the various files.) This f^I^fT " P^^^f'" 

feature also allows the operator to access a second func ^^^'f °" ^ '"^^f^ <^^f^ 1"^/y "^ract infor- 

tion, such as the Activity Log, and enter new informa- f database The Reportmg func- 

tion while in the middle of performing some other task be employed to extract any combmation of 

(e.g. reviewing a diary). Lastly, this feature may be used 35 data required and to output the data m a user designed 
to access infonnation from the Host computer without fomat For example, this function can be used to deter- 
foregoing operations undertake using the local com- ^'J^ ^" o^^f payments for any given time period, 
puter. This is particularly useful when investigating the The Local Data function provides each office with 
details of a policy where policy infonnation is stored on the same number of genenc numenc, date and alphanu- 
the Host 40 fi^^ds (each of which is also of a predetermined 

Just as claims can be assigned to a particular handler, length) to arrange into customized screens. Once these 
they can be reassigned as well. In a preferred embodi- fields have been arranged mto a particular display for- 
ment of the presem invention, the system is capable of mat for use in a local office, they can only be modified 
reassigning one or all of an individual's claims to one or by an operator with the proper level of authonty. Any 
more handlers or supervisor. This is helpful, for exam- 45 number of these fields can be employed and there is no 
pie, when a handler or supervisor is ill for an extended requirement that all/any of them be used. Smce the 
period of time or leaves the office pennanently. The fields are generic, they can be used m any fonnat to 
reassignment is done electronically so that the reas- store any information desired by the local claims office 
signed claims are passed to the new handler intact. The as long as the infonnation confonns to the field designa- 
notice of reassignment is sent to the new handler's or 50 tions. The Local Data function is integrated with Text 
supervisor's "mailbox." processing such that customized forms and letter can be 

As indicated above, when a claim is routed electroni- generated which rely on the information input through 
cally from one person to another, a summary of the a Local Data screen or field. Since the infonnation 
claim, in message form, is sent to a person's "mailbox". input through Local Data is maintained on a local data- 
The mailbox, of the present invention, is analogous to 55 base it is also available for extraction through the Ad 
an electronic in and out box. When a supervisor assigns Hoc Reporting function. 

or reassigns a claim to a handler a message appears on As can be clearly seen, the present invention yields 
the handler's mailbox screen indicating that he has an substantial improvements over prior systems. Other 
assignment. Assignments are viewed through the han- features and advantages of the invention are set forth in 
dler's mailbox, but the complete file may be accessed to 60 the following description and drawings, 
determine the actual steps to be taken. DESCRIPTION OF THE DRAWINGS 

The mailbox screen also indicates to a supervisor 
whether any alerts have been generated (e.g. authority FIG. 1 is a flow chart depicting the manual steps 
level exceeded for check issuance, etc.). This enables a undertaken when a notice of loss is received in a prior 
supervisor to pinpoint certain office problems automati- 65 art claims office. 

cally. FIG. 2 is a flow chart depicting the manual steps 

A number of print queue managers are also provided associated with the use of claim diary in a prior art 
to allow an output operator to monitor the flow of claims office. 



5,182; 

9 

FIG. 3 is a flow chart depicting the manual steps 
associated with the receipt of a claim status inquiry in a 
prior art claims office. 

FIG. 4 is a flow chart depicting the manual steps 
associated with the "closing" of a claim file in a prior art 5 
claims office. 

FIG. 5 is a schematic diagram of a work management 
system constructed in accordance with a preferred em- 
bodiment of the present invention; 

FIG. 6 is an explanatory diagram depicting the con- 10 
struction of an Action Diagram; 

FIG. 7 is an Action Diagram illustrating the com- 
puter program and operative steps of the System Con- 
troller; and 

FIG. 8 is a block diagram depicting the interrelation- 15 
ship of the system functions. 

F. GENERAL DESCRIPTION 
FIG. 5 illustrates schematically a portion 20 of the 
system of the invention. The system portion 20 includes 20 
local data processing equipment at a first station 32, 
Host data processing equipment at a second station 30 
and two separate sets of display input/output equipment 
at two other stations 34 and 36. (Although only two 
display input/output stations 34 and 36 are shown in 25 
FIG. 5, it should be understood that it is preferred to use 
more stations than two.) 

In a preferred embodiment of the invention the Host 
data processing station 30 is located at a remote loca- 
tion. The local data processing station 32, output print- 30 
ing equipment 48 and 52, and the display input/output 
equipment 50 are all located in the claims office. (Some 
display input/output equipment 50 may be located at 
remote stations 34. Communication between the local 
data processing station 32 and this remote display input- 35 
/output equipment 50 occurs via the modem 60.) 

The data processing equipment located at the claims 
office includes a computer CPU 38. The computer is 
preferably a moderately high-speed, high-capacity coin- 
puter such as a Wang VS, however, the computer can 40 
be any general purpose digital computer having suffi- 
cient speed and capacity for processing data in the sys- 
tem. 

Also located at the claims office is a plurality of input- 
/output devices 50, each comprising a keyboard and a 45 
display screen which are used for programming pur- 
poses as well as data input and review. The output 
printing equipment 48 is used to print out checks, forms, 
reports and various types of correspondence. 

A modem 60 is used for sending and receiving data 50 
over telephone lines 64 to a modem 66 provided at the 
Host computer 62. 

When a notice of loss is received in a claims office, an 
operator inputs the information received in that notice 
through the keyboard 68. The information is then trans- 55 
mitted over intraoffice lines 56 to the local computer 38 
which stores the information on a disk at a disk drive 42. 
Information regarding the claims file which is created is 
routed through the intraoffice lines 56 to the electronic 
"mailbox" of a supervisor for review. 60 

Typically, the supervisor reviews the newly created 
file on his display screen 70 and through his keyboard 
68 assigns a claim handler to it and sets aside reserves. 
The supervisor then routes the claim (in the form of a 
claim summary message) to the designated handler's 65 
"mailbox" through the intraoffice lines 56. 

As the claim handler processes the claim he normally 
accesses various functions in the system including the 



diary, the Activity Log, the payment transaction, etc. 
Each function is accessed through a keyboard 68 and 
consists of numerous preformatted screens which are 
displayed on a display screen 70. The functions are 
preprogrammed and run on the local computer 38. The 
information input in response to prompts in the func- 
tions' preformatted screens is stored in the local com- 
puter 38. 

When a form, letter or check needs to be prepared, 
the appropriate function is accessed through a keyboard 
68, the preformatted screens associated with the func- 
tion are displayed on a display screen 70 and any neces- 
sary information input through a keyboard. The output 
to be printed is routed through intraoffice lines 56 to a 
local printer 48 or 52 where it goes into a print queue. 
(Print queue managers are available to control the print- 
ing priority). Upon exiting the print queue, the output is 
printed by the local printer 48 or 52 reviewed and sent 

As mentioned above, the Host computer 62 interfaces 
with the local computer 38. In practice, the Host com- 
puter 62 communicates with the local computer 78 
through its modem 66, the phone lines 64 and the local 
modem 60. In response to a request from the Host com- 
puter 62, the local computer 38 copies certain informa- 
tion stored in the local database and uploads it to the 
Host computer 62 and vice versa. This information then 
resides in both the Host computer 62 and the local com- 
puter 38. It is not removed from the local computer's 
storage facility 42 or 46. 

Other valuable features of the invention will be dis- 
cussed in the more detailed description which follows. 

G. DETAILED DESCRIPTION 
As indicated in the previous section, reference is 
made to the processing of claims to illustrate the fea- 
tures and capabilities of the system and method of the 
present invention. It should be understood that this is a 
description of only on preferred embodiment and other 
embodiments may be accordingly prepared by one of 
skill in the art. 

1. System Security 

In order to prevent the theft of data, the unauthorized 
issuance of checks, system vandalism, etc., a security 
system is provided to limit access to the system of the 
present invention. In one preferred embodiment of the 
present invention, an off-the-shelf security system 
called MENUTECH ® is integrated into the System. 
However, any security system which conforms to the 
below listed criteria can be employed. 

Each employee in an office is assigned to a particular 
security level based on his responsibilities. The security 
level is used to limit the system functions and transac- 
tions which ca be accessed or performed by the em- 
ployee. Initially, each employee is given a User ID 
(usually his initials) and a password which limit his 
system access to his assigned security level. 

When an employee wishes to use the system, he must 
first "Log On" using his User Id and password. Table I 
shows a sample of the first screen displayed on a display 
screen 70 at any terminal 50. (All tables included herein 
are illustrative of screens displayed during the operation 
of a claim processing system called "CAS" for Claim 
Automation System.) 

If the User Id and password are entered correctly, the 
system validates them and a second password screen or 
a Main Menu screen for the operator's appropriate secu- 
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displayed 116. A number of options are available from 
within a menu including: Help, Local Copy, Logoff and 
a variety of application functions 118. Help and Local 
Copy do not cause any change in the system location, 
5 Logoff 120 exits the system entirely, while the selection 
of an application returns the System Controller to the 
Function control position 104. 

If an application function is initially selected 112 the 
record to be acted upon must be selected 122. This 
10 involves either the entry of a new claim number or the 
selection of "Data Carry" when leaving a previous 
function. (The selection of Data Carry carries the same 
claim with its corresponding information to the next 
function.) If Data Carry is not used, the System Con- 
15 troller first checks for any messages and displays appro- 
priate screen indicators 124. It then provides a screen or 
screens which permit the selection of a claim number 
126. 

Once a claim number has been chosen the System 
2° Controller again checks for messages 128 before under- 
taking any business transaction 130. (A business transac- 
tion is the part of a function which changes or creates a 
specific record or set of records.) Any business transac- 
tion can be interrupted 132 to "window" to another 
' function of a different type. The original transaction is 
restored 132 when the operator windows back out of 
the other function. 

Just prior to completing the business transaction the 
operator can place a four letter code in a 'Next Trans' 
field to specify the next function to be undertaken 134. 
When the business transaction is then ended, the func- 
tion is exited and the System Controller returns to the 
The System Controller is a program module that Function Control position 104 to evaluate the next re- 
manages and controls every CAS session. It does this by quested function. (The following is a partial list of avail- 
controlhng the timmg and execution of all CAS func- 35 ^^^^ functions: Loss Processing Transaction, Activity 
tions. The Controller is based on a CAS model transac- ^og, Diary, Directory Tables, Info Search, Payments, 
tion which IS the bluepnnt for every CAS onlme trans- Rgassignments, CAS Secondary Menu and TEXT Pro- 
^'^t!?"' , . . . T^. r ■ / cessing. All the available functions are shown in block 

FIG. 7 IS an Action Diagram of an overview of a - .° j,^ 
successful CAS session. (As shown in FIG. 6, an Action 40 

Diagram is analogous to a sideways flow chart. The 3. Menu Screens 

nested brackets depict various functional steps occur- ^^^^ ^^^^^ ^ ^ ^^^^^^^^ 

nng under the umbrella of other fiinctional steps. Dou- ^^^^^^ ^^j^^^ ^ ^^^i^^^ 

ble lines indicate a loop, while single lines with multiple ^.^r^^^^^iJ, Following a successful logon, the system 

bracket ends md.cate a choice of functions Wording 45 J ^ ^j,^ 

TrVV^^frTLlTwi^Z^^^^^^^ t-' ^P^-fi'^ "-'•^ --rity level. (See, e.g.. Tables 

nature.) As indicated at 102, entry into the CAS system _^ , , . j- „i •„ i,„„ Ji„ „„ j 

must be achieved prior to the takeover of all operations " ^"'J ^o^l^^^^^^ designed for a claim handler and 
by the System Controller 100. After the System Con- a supervisor). The appropriate Pnmary Menu screen fo 
troUer h^ assumed control it first verifies ^hat the re- 50 a particular operator is determmed by a P^fauU Menu 
quested transaction is available for use within CAS 104 Number which is entered m the operator s Staff Table. 
(Primary and default menus are not subject to this veri- 
fication since, if the system is available these menus 
must be available as well. The code to invoke the De- 
fault Primary Menu is given automatically after success- 55 
ful logon and just prior to takeover by the System Con- 
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rity level is displayed. If an incorrect password or User 
Id is entered, a message appears and the operator is 
prompted to re-enter the incorrect term. After five 
unsuccessful attempts, an error message is displayed and 
the operator is locked out of the 
TABLE I 



onday April 19, 1989 



Welcome to CAS 
Please identify yourself by supplying the following information 



Your pass 



system. (An alert is also simultaneously generated to a 
supervisor.) If the password entered has expired (most 
passwords remain active for 30 days) a Password Expi- 
ration screen (not shown) is displayed. This screen per- 2 
mits an operator to select a new password and then 
access the system. It is not necessary to wait until a 
password expires. Rather, passwords can be changed at 
any time through a Password Change screen (not 
shown). 3 

2. System Controller 



troller 106). Once the System Controller 100 verifies the 
availability of the requested function it must insure that 
the operator has the proper authority to invoke the 
requested function 108. This is done by comparing the 60 
function's required authority level with the System 
Security (Menutech) authority level. If the operator has 
the appropriate authority, the function is "run". 

Two types of functions may be invoked, either a 
menu 100 function or an application function 112. If a 65 
menu function is selected, the System Controller 100 
first checks for messages and then displays any appro- 
priate screen indicators 114. Next, the selected menu is 



TABLE II 

SUPERVISOR MENU 



Press a PFKey below or RETURN to do Next 



1) Activity Log 

2) Claim Status Changes 

3) Diary Function 

4) Diary Listing 

5) Directory Tables 

6) Info Search 



10) Mailbox Menu 

11 ) Nature of Paymeni 

12) Payments 

13) Reassignments 

14) Wang OFFICE 

15) CAS Secondary M 
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A Secondary Menu, shown in Table IV is also avail- 
able. This Secondary Menu displays less frequently 
used functions and transactions. Using the Primary 
Menu or the Secondary Menu, an operator can access 
virtually any available system function. 
TABLE III 

CLAIM HANDLER MENU 



a PFKey below or RETURN to 



o Next Trai 



1) Activity Log 

2) Claim Status Changes 

3) Diary Function 

4) Diary Listing 

5) Directory Tables 

6) Info Search 

7) LPT Inquiry 

8) LP Control Change 



32) Logoff 



9) LP Element Change 

10) Mailbox Menu 

1 1) Nature of Payments 

12) Payments 

13) TEXT forms 
Selection/Completion 

14) Wang OFFICE 

15) CAS Secondary Menu 
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input skeletal policy information which, in turn, is used 
to extract policy information from a Policy File which 
may reside in one of the Host Computer's databases or 
in a local database. (Even if some of the policy informa- 
5 tion is maintained in one of the Host's databases, most 
claim's offices have a Policy Index Table which tracks 
the name, address, policy number, etc. of its large ac- 
counts. This Policy Index is available for display 
through the CAS system to assist in the proper extrac- 
10 tion of policy information.) The main element required 
to extract policy information from the Policy File or 
Pohcy Index Table is the policy number. If no policy 
record is found in a Pohcy File or Policy Index Table, 
an explanatory error message is displayed and the infor- 
15 mation must be input manually, (Even if no policy num- 
ber is found, the loss report must still be maintained. 
Therefore, a "non-claim" "record report" is maintained 
on the system.) When information is successfully ex- 
tracted from the Policy File or Policy Index Table, the 
20 initial input fields (i.e. the Interface Screen fields) are 
. protected to preserve the credibility of the extracted 
data. 

Upon completion of the LPT Interface screen, the 
'Enter' key is pressed and a series of loss screens partic- 



System functions are accessed from the Primary or 
Secondary Menus by actuating the "PF" or "Function 
" key corresponding to the desired function (e.g. a PFl 

CI I • J » c*«t,.c i-'i,,^,,^. jcnter Key is prcssca ana a series oi luss sticciis pomi-- 

or Fl key is pressed to access the Claim S^t"^ Change ^^^^ ^ sLrigle "line of business" are displayed. The loss 



function from the Secondary Menu, the PF5 or F5 key 
is pressed from a Main Menu to access the Directory 
Tables function, etc.). 

4. The Loss Processing Transaction 
The processing of a claim begins upon receipt of a 
notice of loss. These "loss notices" are received from 
agents, insureds, customers or claimants, either through 
the mail, in person, electronically or over the telephone. 

TABLE IV 

CAS SECONDARY MENU 



Press a PFKey below or RETURN to 



1) Claim Status Changes 

2) Diary Function 

3) Diary Listing 

4) HTC Sent 

5) Investigate Instrs. 

6) Local OHC 

7) Loss Processing Trans 

8) LP Control Change 

9) LP Element Change 

10) LPT Inquiry 

11) LPT Subsequents 



12) Payment Corrections 



17) Tex' 



It Print 



ction/Completion 

18) TEXT Print Queue 

19) Word Processing 

21) 3270 Emulation 

22) DPSA Security Function 

23) Forms Maintenance 



In a typical claims office, a person called a Claim 
Assistant is primarily responsible for the input of loss 55 
notices into the CAS System. The loss notice informa- 
tion is input through a Loss Processing Transaction 
("LPT") function which may be accessed from a Pri- 
mary Menu (see, e.g., Tables II and III) or by placing 
the four letter code *LPTX' in the 'Next Trans' field of 60 
any transaction. 

The first screen displayed when the LPT function is 
accessed is shown in Table V. This is the Loss Process- 
ing Transaction Interface screen. This screen is used to 



formatted according to a policy symbol 
(indicating the type of poUcy) and the line of business 
specified on the Interface screen. These screens contain 
policy/insured and loss/claim description data. The 
30 number of screens and their sequence is relative to the 
number of claims arising from the loss occurrence and 
the manner in which the loss was reported. 

The initial screens accessed contain fields for input- 
ting required information that applies to the entire loss 
35 occurrence. Reporting screens are used to record infor- 
mation which is specific to an individual claim arising 
out of the loss occurrence. Screens are also available for 
entering Witness, Contact/Comment information and 
Special Procedures, if applicable. Where the notice of 
40 loss is received electronically from agents, insureds, 
customers or a central reporting center, the information 
is in a form which is used to prefiU fields in the LPT. 
The electronically reported information must be re- 
viewed for accuracy but this type of reporting substan- 
45 tially reduces input time. 

The following is a list of screens specific to the auto- 
mobile line of insurance business (which will be used as 
an example for purposes of this description) in their 
logical order of appearance (screens marked with aster- 
50 isks will (potentially) become new claims): 
Policy Information Screen (required) 
Special Procedures (optional unless extracted from 

Policy Index Table) 
Description of Accident (required) 
♦Claimant Screen (required) 

•Physical Damage screen (required for certain types 

of policies — identified by claim symbol) 
•Property Damage screen (required for certain types 
of policies) 

•Injured Party Information screen (required for cer- 
tain types of policies) 
Witness/Passengers screen (optional) 
Contact/Comment screen (optional) 



TABLE V 



LOSS PROCESSING TRANSACTION 



POLICY NUMBER: _ 



SERV EXPEDTR CODE: 



15 

TABLE V-continued 



AGENT CODE: 

LOSS DATE: 

REFT DATE: 

INDICATE LINE OF BUSINESS: _ 



AUTOMOBILE 
PROPERTY/LIABILITY 
WORKERS- COMPENSATION 
FIDELITY/SURETY 



TELEPHONE FIRST REPORT: • LOCAL PREFILL: X 

ENTER) POLICY INFO 6) POLICY INDEX 18) HELP 23) LC 32) CANCEL 



Table VI shows an Auto Policy Information Screen. 
Much of the information necessary to complete the 
input called for by this screen is prefiUed or input 



information can be added, modified or deleted as 
needed. If special procedures are enumerated in the 
Policy Index Table this screen will be prefilled. 

TABLE VII 



SPECIAL PROCEDURES 



PERRY, FREDERICK 



ENTER) ADD 4) PREVIOUS PAGE 18) HELP 23) LC 16) RETURN 
3) NEXT PAGE 



through the LPT Interface screen and the information 
extracted from the Policy File (e.g. Policy Status, Pol- 
icy Number, Agt Code, Loss Date, Insured Name . 
TABLE VI 

POLICY INFORMATION 

POLNUM: 

AGT CODE; AGCY NAME: SALESMAN CODE: 

INSURED: P/C: _ TITLE: 

STREET: 

CITY: ST: _ ZIP: 

BUS PH: RES PH: TIN; 

POL EFF: POL EXP: LOSS DATE: KEPT DATE: 



The Vehicle-Driver Coverage Information screen, 
shown in Table VIII, is used to enter information per- 
taining to the insured driver's coverage limits as well as 



FORMS/ENDT: 

SPECIFY FORMS/ENDT AFF COV: 

EXCESS IND; CERT NUM: LARS IND: LARS LOC CODE: 

SERV EXPEDITER CODE; 

ENTER) VEH-DRIVER 3) SPECIAL PROCEDURES 18) HELP 

27) ERASE LPT 1) CLAIM SET-UP 19) SELF REFER 
23) LC 30) LOCAL DATA 



and Address, etc.) Any additional information that is 
needed to complete this screen is input manually 
through the keyboard. 

The Special Procedures screen, shown in Table VII, 
is accessed from the Policy Information screen and is 65 
used to note any special handling procedures, specific to 
the policy involved, that are required in the processing 
of the claim. Multiple screens are available for input and 



vehicle information such as the make and model of the 
car. Any information which is prefilled to this screen 
can be modified. This screen is generally accesssed after 
information has been entered to the Policy Information 
screen. It may, however, be accessed from a number of 
screens within the LPT. 
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The Description of Accident screen, shown in Table 
IX, is used to enter information that appUes to all claims 
in the Loss Processing Transaction. The information 
includes the accident 

TABLE VIII 
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dent screen and from other screens within the LPT to 
enter any relevant comments about the claim. This 
screen can also be used, for example, to indicate who 
should be contacted for further information if the in- 



CUSTOMER TESTER 



VEHICLE - DRIVER COVERAGE INFORMATION 

02 PH 123123 



LIAB DED AMT: 

SPECIFY IF OTHER COV/LIMITS: 
MI: LOSS PAYEE: 
SPECIFY IF OTHER INSUR ON VEHICLE: 
ENTER -X- IF DRIVER SAME AS INSD: 
DRIVER: 
STREET: 
CITY: 
Lie NUM; 
AGE: 



ST: 



ZIP: 



MED PAY: NON COLL: 

NO FAULT: 
FULL GLASS; 
DED COV: 



REL TO INSD: 



description, location of accident, impact area, time of sured is unavailable. 

loss etc. This screen is generally accessed following A Responsible Party screen (not shown) may be ac- 
input of the Vehicle-Driver Coverage Information cessed from the Description of Accident screen to enter 
screen, it also may be accessed from a number of screens ^° any relevant information indicatmg responsibility for 
within the LPT. the loss. When all available information is entered 
The Witness Information Screen (not shown) is ac- through this screen, pressing 'Enter' automatically re- 
cessed from the Description of Accident screen and is turns the Description of Accident screen to the display, 
used to input basic witness information when necessary A Claimant Information screen, shown in Table X, is 
(e.g. name, address, telephone number, etc.). If informa- used to add claimant information (e.g. name, address, 
tion about more than one witness needs telephone number etc.) to the system. The information 
TABLE IX 

DESCRIPTION OF ACCIDENT LPTX 

CUSTOMER TEST 02 PH 123 123 
DESCRIBE ACCIDENT: 



LOC OF ACCIDENT: 
CITY: 

TIME OF LOSS: 



MPCT AREA: 



ENTER "X" IF SUBROGATION POSSIBILITIES: 
INVEST AUTHORITY: 
VIOLATIONS/CITATIONS: 

KEPT TO: REFT BY: 

COVERAGE REQ: RSK ALRT: QUESTNBLE COV IND: 



to be recorded, a Witness List screen (not shown) is 
available. This screen permits the viewing, addition, 
modification or deletion of witness information. 

A Comments/Contact Information screen (not 
shown) can be accessed from the Description of Acci- 



requested in the Claimant Information screen must be 
input before a claim can be added for that claimant. 
Once this information is input, multiple claims can be 
added for the same claimant as necessary. 



TABLE X 

CLAIMANT INFORMATION 
CUSTOMER TEST 02 PH 123123 

CLAIMANT - ENTER X IF SAME AS INSURED: (IF NOT ENTER DATA BELOW) 
NAME: P/C: TITLE: 
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TABLE X-continued 

STREET: 

CITY: ST: ZIP: 

BUS PH: RES PH; 

AGE: SEX: MS: NUM DEP: 

OCCCODE; STATUS: INCOME RANGE: TIN: 



The Auto-Physical Damage Information screen, ing to any property damaged in the accident. A descrip- 
shown in Table XI, is used, when necessary, to enter tion of the property, the damage, as well as the esti- 
information pertaining to any damage to an insured 15 mated incurred loss and other additional information is 
vehicle. The operator is also prompted to enter a vari- entered through this screen. 

TABLE XII 

AUTO THIRD PARTY PROPERTY DAMAGE 

CUSTOMER TEST 02 PH 123123 

OWNER: CUSTOMER TEST 
PROPERTY DAMAGE 
DESC OF PROP: 

DESC OF DAMAGE: 



OTHER PROP INSD BY: 

ENTER "X" IF DED AMT APPLIES: 

CLM DESC CODE: CLM DESC: 

LOSS TYPE: CLM SYM: COV ID: TOTAL LOSS IND: 

EST INC LOSS: EST INC ALLOC EXP: VERIFIER: 

PTA: JIA: CLAIMS MADE DATE: 



ety of additional information including: incurred loss 40 An Injured Party screen is provided to enter informa- 
information, the estimated incurred allocated expense, a tion about any party injured in the accident (i.e., de- 
repair estimate, etc. scription of the injury, disability dates, claim descrip- 

TABLE XI 

PHYSICAL DAMAGE INFORMATION 
CUSTOMER TEST 02 PH 123123 

OWNER NAME: CUSTOMER TEST 
DESCRIBE DAMAGE TO INSD VEH: 

USED W/PERM? (Y/N): 
REPAIR EST: 

WHERE/WHEN VEH CAN BE SEEN: 



DV ID: TOTAL LOSS IND: 
EST INC LOSS; EST INC ALLOC EXP: 



1) CLAIM SET-UP 13) INJURY 18) HELP 

6)ADDCLMT 3 1) STAT CODING 23) LC 
16) RETURN 11) PHYS DAMAGE 30) LOCAL DATA 



;c.). This screen is shown in Table XIII. 



INJURED PARTY INFORMATION 
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TABLE Xlll-continued 



CUSTOMER TEST 



NAME; CUSTOMER TEST 



DESC OF INJURY: 

TYPE INJURY CODE: DIS BEG DATE: 

ENTER "X" IF DED AMT APPLIES: 



EST INC LOSS; 



COLL SOURCE IND; 



1) CLAIM SET-UP 12) PROP DAMAGE 23) LC 18) HELP 

1 1) PHYS DAMAGE 31) STAT CODING 22) SERVICE PROVIDER 

6) ADD CLMT 16) RETURN 13) INJURY 30) LOCAL DATA 
PACKAGE: DUPLICATE PAYMENT PROBLEM 



A Service Provider screen, (not shown) which may 
be accessed from the Injured Party Information screen 
is used to record the names and addresses of the in- 
dividuals) or institute(s) that provides medical services 
to the claimant. 

A Claim Set-Up screen, shown in Table XIV, is the 
final screen of the LPT. Each claim (at least one for 
each of the asterisked screens on the earlier list) is dis- 
played in summary form, showing the loss type, the 
claim symbol (an internal processing code), the claim- ^0 
ant's name as well as the estimated incurred loss. If 
more claims are involved than space permits, additional 
screens will be generated for those remaining. 



Routing the incomplete LPT generates a message to 
the receiving staff member's mailbox to let him know 
that he should review the incomplete "claim". He, in 
turn, can then route the unfinished LPT to any other 
staff member. There is no limh to the number of times 
this routing can occur. 

Editing of the unfinished LPT can be done by actuat- 
ing certain function keys corresponding to the small 
"secondary" menu on the bottom of the Claim Set-Up 
screen. By using the function keys all of the LPT 
screens can be redisplayed (except the interface screen). 
When a screen is redisplayed it can be edited in accor- 
dance with regular system editing procedures. 

TABLE XIV 



SMITH, JOHN 



CLAIM SET-UP SCREEN 



TELEPHONE FIRST REPORT; 



CLAIMANT #1 
CLAIMANT #2 
CUSTOMER TEST 



10) POLICY INFO 

6) ADD CLAIM 19) SELF REFER 18) HELP 

7) DESC OF ACC 25) MODIFY LOSS 23) LC 

9) MODIFY CLMT 29) VEH-DRIVER 27) ERASE LPT 



From the Claim Set up screen, the LPT can be com- 
pleted, routed to another staff member for additional 
input or review, or edited further. In order to complete 
the LPT all required fields must be validly filled. If all 55 
the required fields are not properly filled, the operator 
is prompted to correct and/or input the appropriate 
information. If the operator is unable to complete the 
required field(s) the LPT will not be completed and the 
claim number(s) will not be assigned. In such situations, 60 
however, pre-determined dummy codes are used to 
maintain the notice of loss. Alternatively, if other staff 
members may be able to provide the necessary informa- 
tion, the incomplete "claim" may be routed to them. 

Routing the incomplete claim is accomplished by 65 
pressing a function key and appropriately completing 
the Route/Process screen shown in Table XV. (This 
procedure is discussed in more detail below). 



When the Claim Set-Up screen is completed, pressing 
the appropriate function key activates an Automated 
Claim Numbering facility. This facility automatically 
assigns a number, from a pre-determined range, to each 
claim or record report of the LPT (record reports are 
given numbers from a separate range from the range of 
claim numbers.). These numbers are the primary 
method of accessing individual claims for processing 
and review. 

5. Routing and Assigning Claims 

Typically, when all the information available from 
the notice of loss has been input through the Loss Pro- 
cessing Transaction, the as yet incomplete LPT is 
routed to a supervisor for review and assignment This 
routing is done through the Route/Process screen, 
shown in Table XV. When the initials of a staff member 
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are placed in the "Route To:" field and 'Enter' is a separate function called the Add Companion Claim 
pressed, the unfinished LPT is routed to the indicated transaction is provided. All information previously 
individual. input through the LPT (e.g. description of the accident, 
TABLE XV 



ROUTE-PROCESS SCREEN LPTX 
INSURED, INC. 02 WEC 123123 

ROUTE TO; ASSIGN TO: SUPERVISOR: 

KEY OFFICE CODE: 

PT; _ NEXT TRANS: DATA CARRY: _ 

ENTER) ROUTE 2) PROCESS 16) HELP 23) LC 16) RETURN 

When the LPT is routed to a staff member he re- etc.) may be viewed in the Add Companion Claim 
ceives a message in his electronic "mailbox". The mes- 20 transaction. The Add Companion Claim Select screen, 
sage comprises a very brief summary of certain informa- shown in Table XVI, is used to select the claim to 
tion already input into the LPT and indicates who which the subsequent companion claim(s) will be 
routed the LPT, the reason for the routing (a referral, added. This screen may be accessed via a Main Menu or 
usually for review in supervisor's case). When the staff by entering 'CCLM' in any 'Next Trans' field, 
member next works on the CAS system, he will be 25 TABLE XVI 

prompted that he has a message waiting (See FIG. 7 ^ CCLM 

steps 114, 124 and 128). ^I^p COMPANION CLAIM TRANSACTION 

When a supervisor retrieves an unfinished LPT from 
the database which has been routed to him for review, 
he typically fills in certain information in the various 30 
LPT screens including the estimated incurred loss, the 

estimated incurred allocated expense, special proce- ENTER CLAIM NUMBER: 

dures, etc. The supervisor's input generally completes 
the LPT. Upon this completion, the supervisor elec- 
tronically assigns the claim to a particular handler for 35 

processing by using a Route/Process screen (see Table ENTER) claim LIST 1 8) help 32) cancel 
XV). When the LPT is complete (complete, meaning all ~~ 
initial information available has been input) and the information screen, the Physical Dam- 

supervtsor assigns the claim, a sequential claim number information screen, the Injured Party Information 

(or record report number) is automatically generated 40 | ' J >^ ^^j^ S^,. 

and assigned by the system to every claim resulting • Companion 

from the loss. (A supervisor in the claims office specifies P ^^.^^ 
various ranges of claim numbers to be used by the sys- f th '1 LPT 

tern through a Number Assignment Transaction screen ?'^ri^n°2f'"^ , r-u . ™ o^i^ 

(not shown)). A claim that has not yet been assigned and 45 ^^ set of LP-Element Change screens are used ^ add 
given a claim number (or record report number) is con- f °f ^ /S'^^'^jf 'nfo""f previously '"put via he 
Tidered to be "in-process." When the claim has been ^PT. An LP-Element Changes screen (not shown) is 
assigned and has been given a claim number (or record f^^^ssed via a Mam Menu selection or by entering 

. _u \ V •, „ »„ 1,= " ECHG m any 'Next Trans field. Each LP-Element 

report number) it is considered to be processed . change transaction is comprised of prefilled screens 

containing essentially the same fields as the correspond- 
ing original LPT screens. Changes are made on a per- 

^„„„ „„ T D-r u»= 1=,=^ «f K= ^Uc.^A screen basis. In other words, information entered via an 

Once an LPT has been completed It cannot be altered r -n-n ■ j- i j L r „ „f 

, , • .,.1. • • 1 T TIT -T-i. » jj LPT IS redisplayed screen-by-screen for correction of 
bv merelv retumme to the oneinal LPT. Thus, to add a ' " " h / j _., „ 



(See, e.g. Table XVII.) 



by merely returning to the original LPT. Thus, to add a 
companion claim arising out of a previously entered loss 

TABLE XVII 

claimant information 

BUMSTEAD, DAGWOOD 02 PH 000999 

CLAIMANT - enter X IF SAME AS INSURED: (IF NOT ENTER DATA BELOW) 

NAME: P/C: TITLE: 

STREET: 

CITY: ST: ZIP: 
BUS PH: RES. PH: 

AGE: SEX: MS: NUM DEP: 

OCCCODE: STATUS: INCOME RANGE: TIN: 



5,182,705 

25 

TABLE XVII-continued 



1 1) PHYS DAMAGE 13) INJURY 18) HELP 16) RETURN 

12) PROP DAMAGE 30) LOCAL DATA 23) LC 

p There are two ways to change element information 
previously input via the LPT. 

1. Overlay 

The cursor is moved to the desired field location on 
the display and the original information in that field is 
typed over. This continues through each succeeding 
field requiring modification. If the modified information 
has fewer characters than before, any extra characters 
may be deleted by erasing to the end of the field. 

2. Deletions 

This method is used to remove all the information in 7. Review of Claim Files 

a field. The cursor is placed in the first character space An LPT Inquiry function is used to view claims after 

of the field and the "Erase Key" is pressed. This deletes they have been processed (through the LPT). The LPT 

all the information in the field. Inquiry transaction, available for viewing purposes 

"Control Changes" are changes to any of the follow- only, consists of a series of screens which are essentially 

ing: a claim number, a claimant name, or a policy num- the filled screens of the current LPT. 

ber. These are essentially fundamental changes which Xo review any claim using the LPT Inquiry function 

impact the accessibility of the entire loss transaction. the claim number must be entered through an LPT Loss 

An LP-Control Changes Menu is used to designate Inquiry screen shown in Table XX. The LPT Loss 
the desired control change and claim number (See Inquiry screen is accessed via the Main Menu or by 
Table XVIII). First, the entire claim number is entered. inputting 'LPTF in the 'Next Trans' field of any trans- 
Then, the appropriate function key is selected for the action. 

TABLE XIX 

LP - CONTROL CHANGES 
CLAIM NUMBER 



INSURED: JOHNSON, RICHARD P/C: P TITLE: MR 

CLAIMANT: JONES, PETER P/C: P TITLE: MR 

POLICY NUMBER: 02 PH 120000 

CLAIM NUMBER: 023 AP 00103 

NEW CLAIM NUMBER: 

LOCAL ONLY UPDATE: PT: PTA: NEXT TRANS: 

DATA CARRY: 

ENTER) CHANGE CLAIM 23) LC 18) HELP 32) CANCEL 



TABLE XVIII-continued 

1) CLAIM NUMBER/RECORD REPORT CHANGE 

2) POLICY NUMBER CHANGE 

3) DELETE LINKAGE 

4) CHANGE LINKAGE 

5) CLAIMANT NAME CHANGE 



Control Change function desired. 

By way of example, an LP-Control Changes Claim 
Number screen is shown in Table XIX. This screen is 
displayed following the selection of the Claim Num- 
ber/Record Report Change function on the LP-Control 
Changes Menu screen. The majority of the information 
on LP-Control Changes Claim Number screen is pre- 
fiUed with the existing control information. However, a 
field is provided for entry of a new claim number. When 
the new claim number is entered, this transaction is 
processed and a comment providing both the old and 
new claim number is automatically generated to the 
Activity Log (discussed in detail below). 
TABLE XVIII 

LP ■ CONTROL CHANGES 

MENU 65 



CLAIM NUMBER: 



A loss Assignment/Inquiry— Claim Summary screen, 
shown in Table XXI, is displayed in response to the 
entry of the claim number in the LPT Loss Inquiry 
screen. This screen lists all 

TABLE XX 

LOSS INQUIRY 



CLAIM NUMBER; 023 AC 13131 



ENTER) VIEW INFORMATION 16) RETURN 

claims associated with the claim number entered (i.e. 
the claim requested and all companion claims). Posi- 
tioning the cursor next to the desired claim and pressing 
'Enter' displays a filled Claim Information screen. From 
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n example of oi 



AUTO LOSS ASSIGNMENT/INQUIRY SUMMARY SCREEN 

INSURED: DARBY ENTERPRISES 

300 COMPOSER AVENUE BUS PH: (203) 528-8881 

WEST HARTFORD CT 06102 RES PH: 

POL NUM: 37 DP 100111 AGENCY: 

CLM DESC: WITNESS: > 

LOSS DATE: 08/01/88 TIME OF LOSS; 06P REPORTED DATE: 

TELEPHONE FIRST REPORT: 
CLAIM NUMBER CLAIMANT 
023 AC 13131 DARBY ENTERPRISES 

300 COMPOSER AVENUE 

WEST HARTFORD CT 06102 



ENTER) SELECT CLAIM 7) SELECT CLAIMANT 12) ADD DIARY ENTRY 

16) RETURN 4)PREVCLAIM 10) POLICY INFO 

14) ACTIVITY 17) NT 5) NEXT CLAIM 

IDDESCOFACC 29) VEH-DRIVER 23) LC 



8. Transfer of Claims Between Claims Offices 
Claims initially received, set-up, and numbered in one 
office may need to be transferred to another office to 
Handle to Conclusion (HTC) due to a change in the 
claimant's or insured's address (or other change in loca- 
tion). To do this, the originating office completes an 
HTC Sent transaction, through CAS, and electronically 
transfers the claim file to the new claims office. 



the sending office field (marked with asterisks). 

' A "Service Item" is a request by one claims office to 
another claims office for a partial investigation of a 
claim that is being handled by the first claim office. 
Such requests can include obtaining a police report, a 
signed statement, etc. A Service Item request may be 
mailed or electronically transferred to a receiving of- 
fice. If the request is mailed it must be manually input 
into the CAS System via a Service Item 

TABLE XXII 

PHYSICAL DAMAGE INFORMATION 



BURMINGHAM, TED 

OWNER NAME: BURMINGHAM, TED 
NUMBER; • 

DESCRIBE DAMAGE TO INSD VEH: 



USED W/PERM? (Y/N): 
REPAIR EST: 

WHERE/WHEN VEH CAN BE SEEN: 



EST INC ALLOC ESP: 



TOTAL LOSS IND: 
VERIFIER: 



The HTC Received Transaction screens are almost 
identical to the LPT screens and follow the same screen 55 
flows and completion procedures. The difference be- 
tween the HTC Received screens and the LPT screens 
is the addition of a claim number field, a sending office 
field and the removal of the claim symbol field as a 
separate field. For example, for the automobile line of 60 
business LPT, the additional fields appears on the Phys- 
ical Damage Information screen, the Auto Third Party 
Property Damage screen and the Injured Party Infor- 
mation screen. 

When the HTC Received transaction is accessed, an 65 
Interface screen returns which is identical to the LPT 
Interface screen and follows the same completion pro- 
cedures and subsequent screen flows. Shown below in 



transaction. If the request is transferred electronically, 
the Service Item transaction screens prefiU. In such 
cases, when the Service Item request is received it goes 
to a predesignated supervisor's mailbox for review and 
assignment. The Service Item transaction screens (not 
shown) are similar to the LPT screens and follow the 
same screen flows and completion procedures. The 
difference between the Service Item screens and the 
LPT screens is that not as much information is required 
for processing a Service Item and the Service Item 
screens contain fields for recording Requesting Office 
information (e.g. name, code, etc). 
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9. Staff Tables 
The Staff Tables function maintains information rele- 
vant to the claim office personnel. This information 
includes authority level, case load maximum, job title, 5 
etc. for each staff member. Supervisors determine the 
proper reserve authority level, payment authority level, 
diary limit, case load amount, etc. for each staff mem- 
ber. Only claim office personnel having the proper 
authority are able to view, update, and or delete infor- 10 
mation on the Staff Tables. 
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When a new staff member needs to be added to the 
staff tables a screen entitled Valid JDC-AMC Combina- 
tions, show in Table XXIV, is typically accessed first. 
This screen is a prefilled table of job descriptions appli- 
cable to a claim office. By positioning the cursor on the 
appropriate job description and pressing "Enter" the 
selected job description pre-fiUs into an Add Staff Mem- 
ber screen. This Add Staff Member screen is used to 
input the various authority levels, system IDs and other 
information regarding the new staff member. (See Table 
XXV). 

TABLE XXIV 



VALID JDC - AMC COMBINATIONS 



GENERAL ADJUSTER 
HEALTH SERVICES REP 
OUTSIDE CLAIM REP 
OUTSIDE CLAIM SPECIALIST 
OUTSIDE SENIOR CLAIM DEP 
RESIDENT CLAIM REP 
CLAIM PROCESSOR 
INSIDE CLAIM REP 
INSIDE CLAIM SPECIALIST 
INSIDE SENIOR CLAIM REP 
TELEPHONE CLAIM REP 
CLAIM ASSISTANT 
OFFICE SERVICES UNIT 
SYSTEM ADMINISTRATOR 



When the Staff Table function is accessed, the opera- 
tor can: view a particular staff member's table; add staff 
members to the staff directory; search for a particular 35 
staff member; or modify information on the Staff Table. 
The ability to perform any or all of these functions is 
entirely dependent on the operator's Staff Table author- 
ity. To view all the members of the staff a Staff Direc- 
tory screen (shown in Table XXIII) is available. This 40 
directory will display on multiple screens, if necessary, 
depending on the number of staff members. 

TABLE XXIII 



LAST NAME 

ANDERSON 

ANDREWS 

ASHTON 

BALD 

BARNES 

BARR 

BARR 2ND 

BEARSE 

BECKER-JONES 

BECKLES-MITCHELL 

BELISLE 

BELL 

BENSON 



STAFF DIRECTORY 



FIRST NAME 



SUSAN 

ANNE 

PAULA 

LISA 

DWAYNE 

ROBIN 

ROBIN 

ELIZABETH 

PAM 

BRENDA 

JOANNE 

ANNE 

RON 



6) ADD 9) MODIFY 16) RETURN 

7) FIND 18) HELP 23) LC 



In order to view, modify or delete a particular staff 
member's table, the cursor is placed next to the name of 
that staff member and 'Enter' is pressed. Alternatively, 
a Find Staff Member screen (not shown) is available for 
directly accessing a particular staff member's screen. 
All that is necessary is to input that individual's initials 
or last name. 

When a supervisor wishes to check on authority lev- 
els and/or other parameters for a staff member, a Staff 
Member Inquiry screen can be accessed to view the 



OCR 

osu 

OCR 



current settings. This screen 
TABLE XXV 

ADD STAFF MEMBER 



STAFF TABLE FOR: 
LAST NAME: 



TABLE XXV-continued 



FIRST NAME: 
LOGON ID: 
JOB TITLE: 
UNIT: 
AMC: 

JOB DESCRIPTION CODE; 

SUPERVISOR; 
PAYMENT AUTHORITY; 
RESERVE AUTHORITY: 
OUT OF OFFICE; 
CASELOAD/NEW ASSIGNMENTS; 

DIARY LIMIT PER DAY: 
GENERATE SUPV DIARY - COMPENSATION; 
DIARY ROLLOVER LIMIT - DAILY; 
STAFF TABLE AUTHORITY: (A-B-CD-E) 

OTHER TABLE AUTHORITY: O'-N) 
AUTHORIZER; 



UNIT NUMBER; 
DEFAULT MENU NUMBER; 

STATE LICENSE NUMBER; 
ALERT MSG REC: 

TRANS REVIEW: 



"ALL OTHERS": 
PER CLAIM: 
TERMINATION/TRANSFER DATE: 
PRIMARY OFFICE CODE: 
UPDATER: NEXT TRANS: 



13) VALID ADMINISTRATIVE UNITS 



23) LC 



is shown in Table XXVI. 

AdditionaJ screens are available within the Staff Ta- 
bles function to modify staff member information and to 
delete staff members from the file. 

The Staff Table function and the Staff Tables created 
through that function are an extremely important piece 
of the CAS system. The Staff Tables are integrated with 
virtually every other function in CAS. For instance, 
before an operator can even access CAS functions, the 
User ID which has been input is 

TABLE XXVI 



20 permit supervisors and other claim office managers to 
. monitor the case loads of individual staff members, 
claim units and the office as a whole. This series of 
reports can include information such as monthly claim 
openings and closings, the number of claims handled by 

25 line of business, and total caseload counts. The Caseload 
Monitoring function can also provide a Current Claim 
Distribution report. This report, which can be done by 
individual staff member, claim unit or the entire office, 
shows the number of claims of a specific monetary 



STAFF MEMBER INQUIRY 



STAFF TABLE FOR: 
LAST NAME; 
FIRST NAME: 
LOGON ID: 
JOB TITLE; 
UNIT: 
AMC: 

JOB DESCRIPTION CODE: 
SUPERVISOR; 
PAYMENT AUTHORITY: 
RESERVE AUTHORITY; 
OUT OF OFFICE; 
CASELOAD/NEW ASSIGNMENTS; 

DIARY LIMIT PER DAY: 
GENERATE SUPV DIARY - 
DIARY ROLLOVER LIMIT - 
STAFF TABLE AUTHORITY; 
OTHER TABLE AUTHORITY: 
AUTHORIZER; 

ENTER) NT 18) HELP 



UNIT NUMBER: 03 
DEFAULT MENU NUMBER: 01 
STATE LICENSE NUMBER: 

ALERT MSG REC; EWW 
TRANS REVIEW; N (Y/S/N) 



COMPENSATION: "ALL OTHERS"; 

DAILY; PER CLAIM; 

A (A-B-C-D-E) TERMINATIONA'RANSFER DATE; 
Y (Y-N) PRIMARY OFFICE CODE: 5 1 5 

RAB UPDATER: DML NEXT TRANS: 



16) RETURN 



23) LC 



compared to the staff initials specified in the Staff Ta- 
bles. If no match is found, the operator will not be able 
to access any CAS functions. Once the operator has 
successfully logged on, the System Controller must 
look to the Staff Tables to display the proper Primary 55 
Default menu which is indicated in the Default Menu 
Number field of the user's Staff Table. Still further, the 
Staff Tables are referenced to properly route alert mes- 
sages, to limit function access, to limit payment and 
reserve activities, to prefill operator information for 60 
Activity Log entries and to specify when diary and 
authority level alert messages will automatically be 
generated. In each of these cases, the Staff Tables are 
referenced to insure the proper operation of other sys- 
tem functions which are user specific. 65 

Another available function, which is a derivative of 
the Staff Tables, is the Caseload Monitoring function. 
This function can produce a series of reports which 



range which are being handled. This is an important 
management tool since higher valued claims generally 
require substantially more time and effort to complete. 

10. Directory Tables 
The Directory Tables function is used to store and 
display names, addresses and other pertinent informa- 
tion about currently used services and individuals. 
These include attorneys, doctors/hospitals, investigat- 
ing authorities, etc. Each listing in the directory tables is 
automatically assigned a unique directory code upon 
initial input. (The code includes a category designation 
so that, for example, a list of defense attorneys can be 
readily displayed.) The Directory Tables function then 
interacts with various other functions including the 
LPT, Payment and TEXT Processing functions to pre- 
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fill the name and/or address information when the di- 
rectory code is input into one or more fields on these 

When the Directory Tables function is accessed the 
first screen which is displayed is the Directory Tables 5 
List screen, shown in Table XXVII. This screen is a 
listing of entries in the Directory Tables. (The Direc- 
tory Tables List screen will automatically display the 

appropriate category of entries for filling in certain 

empty text fields during Text Processing. In such cases 10 
placing the cursor on the correct listing and actuating 
the correct function key will fill in the blank field.) In 
order to access all the information associated with the 
entry, the cursor can be placed next to the entry and 
'Enter' pressed. A Directory Table Display screen, 15 ^^^^^ 
shown in Table XXVIII, then appears displaying the nami 
information applicable to the particular entry. Alterna- 
tively, a Directory Tables Inquiry screen, shown in 
Table XXIX, can be used to search for the particular ^j^g 

entry. 20 

TABLE XXVII 



TABLE XXVIII-continued 



NEXT TRANS; 



TABLE XXIX 

DIRECTORY TABLES INQUIRY SCREEN 



DIRECTORY T. 



S LIST SCREEN 



LASSERMAN, TAMMY E. 

D'ANGELO & D'ANGELO, LAW OFFICES OF 

KARSH. DIANNE 

STEVENSON, JACOBS & ROSE PC 

JOHNSON, DAVID LEE 

JOHNSON, DAVID LEE 

GILLEY, HINKEL & BROWNE, ATTYS AT LAW, PC 
JAMESON, HENRY 
FOY, MICHAEL 

LINCOLN, WASHINGTON, ROOSEVELT & KENNEDY, PC 

ROGERS & ROGERS PC 

HURLEY, MARY 

WALBACK AND WALBACK PC 



ENTER) DISPLAY 4) PREV/FIRST 6) ADD 8) DELETE 16) RETURN 
5) NEXT/LAST 7) FIND 9) MODIFY 17) NT 

23) LC 18) HELP 



TABLE XXVIII 



DIRECTORY TABLES DISPLAY SCREEN 



NAME: PEARSON, BAUK & WEINSTEIN 



To add an entry to the Directory Tables, a Directory 
Tables Add screen, shown in Table XXX, is available. 
When the input fields have been filled and the 'Enter' 
' key is pressed, the new entry becomes part of the Direc- 
tory Tables list. 

TABLE XXX 



DIRECTORY TABLES ADD SCREEN 



CODE: 
NAME: 
TITLE: 
STREET: 
(OPTIONAL): 
CITY: 
STATE: 
ZIP CODE: 
TELEPHONE: 
TIN: 
TR CODE: 



NEXT TRANS: 
ENTER) ADD 18) HELP 23) LC 32) C 



3) ACCEPT DUPLICATE 



TITLE: ATTY 

STREET: 1000 FARMINGTON AVENUE 
(OPTIONAL): 65 

CITY: HARTFORD 

STATE: CT 

ZIP CODE: 06115 

TELEPHONE: (203)548-0011 



Additional screens (not shown) are also provided to 
delete and modify individual entries. The screen struc- 
ture and format is very similar to that used for the Staff 
Tables function. 
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Carry' function key and placing the appropriate code in 
11. Into Search ^j^^ .j^^^^ .j.^^^^, jj^j^j ^^^^^ ^^^^^^ function. 

The Info Search Facility provides the ability to Off-line Information is displayed in the same manner 

search for information resident on the local data base through separate Off-Line Claim Information screens 

(on-line) as well as data that has been purged to an 5 (not shown), 

off-line database. Info Search will access both "in pro- , . . , 

cess" and "processed" claims. 1 1" ^'^"^"y 

The Info Search Facility screen, shown in Table The Activity Log is a record of the key activities 

XXXI is accessed via a Main Menu selection or by involved in the processing and adjustment of a claim, 

entering 'SRCH' in the Next Trans' field of any transac- 10 The Activity Log is created in one of two ways. A 

tion. The Info Search Facility performs searches by claim handler, supervisor or other staff member can 

using any of the following criteria: (1) claim number; (2) create an Activity Log via input of a claim number to an 

claimant name; (3) insured name; and (4) policy number. Activity Log Select screen shown in Table XXXII 

One or more of these pieces of information may be input (This screen is also used to access an existing Activity 

through the Info Search Facility screen. If exact spel- 15 Log). Ahematively, the system will create an Activity 

lings of names are not known, phonetic translation, a Log automatically, if one does not already exist, when 

technique that puts a similar sounding or spelled name/- an operator moves directly to the Activity Log function 

text to a numeric equivalent or phonetic key, is used by for a specific claim. If another CAS transaction gener- 

the System to assist in the location of the records. If the ates a comment to the Activity Log and the Log does 

entire name is not known, the system will also search on 20 not already exist, it will likewise be automatically cre- 

a partial name. To further restrict the search and limit ated. 

the number of records returned, additional information An Activity Log Comments screen, shown in Table 

about the claim(s) can be input through the Info Search XXXIII, is pre-fiUed and displays all comments pres- 

Facility screen (such as loss date, insured address, ently in the Activity Log. There is no Umit to the num- 

claimant address, etc.) 25 ber of Comments screens in an Activity Log. The 

A Select Applicable Insured Information screen (not screens within the Activity Log are displayed in reverse 

shown) is displayed when the insured name is searched chronological order allowing the operator to view the 

through the Info Search Facihty screen and multiple most recent entries to the Log first. 

TABLE XXXII 

ACTIVITY LOG SELECT 



ENTER) ACTIVITY LOG 18) HELP 16) RETURN 23) LOCAL COPY 



TABLE XXXI 



INFO SEARCH FACILITY 

INSURED: 
CLAIMANT: 

:LM NUMBER: POL NUMBER: 

IF KNOWN, ENTER THE FOLLOWING INFORMATION: 

LOST DATE: SEEK TERM: THRU 

ST: ZIP: 



ENTER "X" IF OFFLINE 



ENTER) SEARCH 10) NAME EXACT MATCH 18) HELP 23) LC 16) RETURN 



Once the desired claim is found, the operator may 
acquire further detailed information by accessing the 65 
Activity Log or the LPT Inquiry function (to deter- 
mine the nature of the claim) screens from the Claim 
Information screen or by pressing a 'Next Trans/Data 



Any time an entry is made to the Activity Log, the 
claim number, insured name, claimant name, loss date, 
claim description and estimated incurred loss fields are 
pre-fiUed. All these fields are protected and cannot be 
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TABLE XXXIII 

ACTIVITY LOG COMMENTS 

CLM NUM: 023 C 00002 CLMT: BAILEY, BILL 

LOSS DATE: 03/03/89 
EST INC LOSS: 250 

HAND: LLB SUPV: RJM INITIAL RESERVE: 250 

03/03/89 JACKET INDEX NON SCAN - DLSA: 
03/03/89 JACKET INDEX NON SCAN - DLSC: 

6) ADD COM 10) INDEX 14) POL LIMITS 17) NT 16) RETURN 

7) SELECT 12) DIARY FUNCTN 15) DIARY LIST 

18) HELP 23) LC 19) PAYMENT COM 



modified by the operator. When a comment is automati- desired claim by positioning the cursor next to the claim 
cally generated to the Activity Log, these fields are number and pressing the appropriate function key. 

TABLE XXXIV 

ACTIVITY LOG ADD 



CLM NUM: 
INSD: 
CLMT: 
CLM DSC: 



023 C 00002 POL NUM: 00 GNR 010101 

STRADLIN, IZZY 
BAILEY, BILL 



6) ADD COMMENT 18) HELP 



likewise prefilled and protected. In fact, every field in Within the Activity Log function, a Modify screen 
the Activity Log is protected once an entry has been (not shown) is available to modify or input the Destroy 
made. This provides an audit trail for any necessary Date, the Coverage Requested Date, the Coverage 
claim review. Received Date and the Comment field of the Activity 

An Activity Log Index screen, shown in Table Lot Index. This information may appear pre-fiUed if 
XXXV, is provided to show the general status of a these dates or comments were previously entered or 
claim and serves as an index to multiple claims of a ^° generated. If the fields are pre-fiUed, they can be modi- 
particular loss occurrence. The Activity Lot Index fied by overlaying the information. If there are no pre- 
screen, which is prefilled, can be used to select the filled dates or comments, the correct date or comment 

can simply be added in the blank field. 

TABLE XXXV 

ACTIVITY LOG INDEX 

INSURED: STRADLIN, IZZY 

POL NUM: 00 GNR 010101 LOSS DATE: 03/03/89 DESTROY DATE: 

COV REQ: COV. REC: 

OCC RESERVE: 250 POLICY STATUS; LAPSE STATUS: 

COMMENTS: 

CLAIM NUMBER CLAIMANT EST INC LOSS STATUS 



ENTER) ACTIVITY LOG 9) ADD/MODIFY' 18) HELP 
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TABLE XXXV-continued 



14) POL LIMITS 



An Activity Log Payment Comments (not shown) is 
available for viewing. This screen is pre-filled and dis- 
plays all payment comments which have been automati- 
cally generated to the Activity Log. This provides a 
quick, efficient way to evaluate a claim's payment re- 

13. Claim Reassignment 
There are three types of reassignment transactions: 
claim; family; and global. A Claim Reassignment trans- 
action is avdlable through a Claim Reassignment screen 



5 the time of the closing; (2) reopen a closed claim that is 
to remain open; or (3) change the reserves on an open 

A Claim Status Change Menu, shown in Table 
XXXVI, lists each of the Claim Status Change transac- 
10 tions available for selection. A Claim Status Changes 
Claims Select screen (not shown) is used to enter the 
claim number for which a change is required. This 
screen is displayed after selection of an type of Claim 
Status Change through the Claim Status Change menu 

TABLE XXXVI 

CLAIM STATUS CHANGES 



PRESS A PF KEY BELOW OR RETURN TO DO NEXT TRANS: 

1) CLAIM STATUS CHANGE - CLOSE 

2) CLAIM STATUS CHANGE - REOPEN 

3) CLAIM STATUS CHANGE - RESERVE 



16) RETURN TO PREVIOUS MENU 
32) LOGOFF 



(not shown) to reassign a single new claim to a different 
claim handler and/or supervisor. A Family Reassign- 
ment transaction is available through a Family Reas- 
signment screen (not shown) which is used to reassign a 35 
family of claims to a new/different claim handler and- 
/or supervisor. Lastly, a Global Reassignment transac- 
tion is available to reassign all open claims from one 
claim handler and/or supervisor to another claim han- 
dler and/or supervisor. The latter is accomplished ^ 
through a Global Reassignment screen (not shown). 
This transaction requires a high security level and can 
only be undertaken by certain staff members. 

14. Claim Status Changes 
A Claim Status Change function is used when one of 
the following activities is required on a claim file: (1) 
close a claim when no closing check is being issued at 



Either a Claim Status Change-Close Transaction or a 
Final/Close Payment transaction is required to close a 
claim. If a Final/Closed Payment check is issued, the 
Closing Payment transaction will close the file. If the 
claim is being closed without a payment, the Claim 
Status Change-Close transaction must be used to close 
the claim. A Claim Status Change-Close screen, shown 
in Table XXXVII, is accessed from the Claim Select 
screen after the selection of "Claim Status Change- 
Close" n the Claim Status Changes Secondary Menu. 

There are two types of claim reopenings. They are: 
(1) reopen/close to issue a payment and to close the 
claim again in one transaction using a Payment Reo- 
pen/Close transaction; and (2) a 



TABLE XXXVII 

CLAIM STATUS CHANGES - CLOSE 

CLAIM NUMBER: 023 L 00003 POLICY NUMBER: 02 SCC777777 

INSURED: THE DUPONT CORPORATION 
CLAIMANT: JERKINS, HARRY CLAIMANT STATUS: 

LOSS PAID: 0.00 ALLOCATED EXPENSE PAID: 0.00 

SUBROGATION EXPENSE; 0.00 SALVAGE EXPENSE: 

REFUND EXPENSE: 

CLAIM ACTION CODE: 0 SUIT RESULT CODE: 

COLLATERAL SOURCE/TOTAL LOSS IND: 

DISABILITY BEGINNING DATE: DISABILITY ENDING DATE: 

LOCAL ONLY: DESTROY DATE: 

PTA: NEXT TRANS: DATA CARRY: 



2) PROCESS 18) HELP 23) LC 30) LP 32) CANCEL 



reopen that is to leave the claim open using a Claim 
Status Change-Reopen transaction. A regular Payment 



the LPT and the Estimated Incurred and Paid fields 
will prefill with the most current totals. 
TABLE XXXIX 



RESERVE CHANGE 



CLAIM NUMBER: 023 L 00003 POLICY NUMBER: 02 SCC 777777 
INSURED: THE DUPONT CORPORATION 
CLAIMANT: JERKINS, HARRY 

INITIAL RESERVE: 1,200 



LOSS: 

ALLOCATED EXPENSE: 
LOSS VERIFIER: 



LOCAL ONLY: 



ASSIGN TO: MKZ SUPERVISOR: COM 
NEXT TRANS: DATA CARRY: 



2) PROCESS 18) HELP 



30) LP 32) CANCEL 



n is used to reopen and close a claim if an 
additional payment is made and the claim does not need 
to remain open. 

A Claim Status Changes-Reopen transaction is re- 
quired to reopen a claim which will remain open. The 
loss type will remain the same as it is when the claim 
was closed. A Claim Status Change-Reopen screen, 
shown in Table XXXVIII, is used to perform this trans- 
action. If the closed claim is not found using the On- 
Line Info Search Facility the Off-Line Info Search 
Facility is used. 

TABLE XXXVIII 



2 J 15. Text Processing 

The Text Processing function provides the ability to 
perform various types of text processing without leav- 
ing the CAS system. Text Processing can generate pre- 
formatted documents and pre-fill blank fields^ in the 

30 documents' bodies by extracting information input 
through other system functions. Upon operator request, 
all applicable information, previously input into CAS 
via other transactions (e.g. LPT) is pre-filled into the 
requested document. In the event that all the informa- 



CLAIM STATUS CHANGES ■ 

CLAIM NUMBER: 023 L 00003 POLICY NUMBER: 02-SCC 777777 

INSURED: THE DUPONT CORPORATION 
CLAIMANT: JERKINS, HARRY 



LOSS: 

ALLOCATED EXPENSE: 
LOSS 



DISABILITY BEGINNING DATE; 
LOCAL ONLY: ASSIGN TO: 

PTA: NEXT TRANS: 



DISABILITY E 

SUPERVISOR: 
DATA CARRY: 



2) PROCESS 18) HELP 23) LC 30) HOLD 32) CANCEL 



A Claim Status Changes-Reserve Change transaction 
is required to change the estimated incurred loss and/or 
estimated incurred allocated expense on open claims 
(The estimated incurred allocated expense is the amount 
of money that is expected to be spent by claims office 
for investigation of a claim). When a Reserve Change is 
processed, a comment is automatically generated to the 
Activity Log. A Claim Status Changes-Reserve Change 
screen, shown in Table XXXIX below, is used to com- 
plete this transaction. The claim number, policy num- 
ber, insured and claimant name fields will pre-fill with 
the previously entered information. The Initial Reserve 
field will pre-fill with the original that was entered in 



55 tion necessary for form completion cannot be extracted 
from the system, the Text Processing function prompts 
the operator to manually input the additional informa- 

A core group of generic forms are preformatted for 
60 use in all claims offices. However, each claims office 
can customize its own forms. This customization re- 
quires the creation of a form in "Word Processing" (A 
Word Processing function is provided with Wang® 
brand equipment, however, this function is available 
65 with virtually every other available system. The Word 
Processing function is generally accessed through a 
"Wang (D Office" menu selection.) After the form is 
created it is brought within the Text Processing func- 
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appropriate type of Directory entries (e.g. all Doctors, 
or all investigators, etc.) for the particular empty field. 
If a designation is made (i.e. placing a 'V in the 'X OR 
V field) the system wiir display the Document Comple- 
n (even if the document is 100% completed) 
so that the requestor may view, modify and/or com- 
plete the document prior to sending it to the print 
queue. Each Document Completion screen is unique for 
each specific document. Any blank fields displayed o 



tion where it is coded so that all blank fields will prefiU. 
Thus, a local claims office is not constrained by the 
Preformatted forms. 

A Document Claim Selection screen (not shown) is 

used to select the claim(s) for which documents are 5 
needed. A Document Claim Request screen, (not 
shown) is used to select the particular claim for which 
correspondence is desired. A Document Request 

screen, shown in Table LX, displays a list of preformat- ^ . . 
ted documents applicable to the selected claim. From 10 the Document Completion screen are those which the 
this screen an operator may select the specific form(s) to system was unable to complete with the available sys- 
be printed. Only those documents appropriate for the tern information. Fields which are necessary in order to 
type of claim which has been input are listed. If multiple generate the document, are highUghted and underiined. 
claims are selected for correspondence generation, form A document cannot be sent to the print queue if a re- 
hsts are displayed one at a time for each claim. 15 quired field is blank. Ultimately, if a required field can- 
Text Processing pulls applicable information from not be filled, the document request must be cancelled, 
within the system and pre-fiUs as many fields requiring Some forms are generated automatically without any 
completion as possible. If all the required fields are operator intervention. This may occur, for example, 
completed and if a particular designation is made (i.e. when an LPT is processed, or when certain LPT 
placing an 'X' in the *X OR V field), the system auto- 20 screens are completed and a form is generated to pro- 
matically sends the document to the appropriate print vide system or legal backup for the loss notice. If the 
queue. If the system is unable to pre-fiU all of the fields, system reaches an automatic form generation point, and 
the requester is prompted to input the necessary infor- the necessary information to send the form to the Text 
mation via a Directory Completion screen (if the infor- Processing Print queue is unavailable, an alert message 
mation is contained in a directory table) or with a Docu- 25 is generated. 

ment Completion screen (if the information is not con- The CAS system also supports the preparation of free 

tained anywhere in the system). form documents through the Word Processing func- 

The Directory Completion Screen, shown in Table tion, as indicated previously. This permits an operator 

XLI, is associated with the Directory Tables function. to type any letter or form that is needed. The usual edits 

It lists the 30 are available to permit the revision of any errors. 

TABLE XL 



DOCUMENT REQUEST 



CLAIM NUMBER: 023 AC 00001 
INSURED: SMITH. JOHN 
CLAIMANT: SMITH, JOHN 



DOCUMENT NAME 
CP-16 CLAIM RECOVERY ESTIMATE - 
ACKNOWLEDGE AND REQUEST FOR INFO 
FILE TRANSFER 

ACKNOWLEDGE OF CLM -NO INFO ML- 10 
ASR ASSIGNMENT SHEET INSD AUDTX 
ADR-ML 1 1 

APP BENEFITS AUTO/PROP LC-5069-1 

ACKNOWLEDGEMENT LETTER TO AGENT WTCHR 

ASR ASSMT SHT INSD NON-AUDA - DLSA 

ATTORNEY ACKNOWLEDGEMENT 

ASR ASMT SHT-CLMT - AUDA LC 5344 

CLAIM FOR DAMAGES LC-2474 

ASR ASMT SHT-INSD - AUDA LC 5344 

CLAIM FOR DAMAGES PROPERTY LC4556 



HANDLING INSTR 



ENTER) SELECT 



TABLE XLI 



DIRECTORY TABLE 

POSITION CURSOR AND PRESS ENTER FOR DESIRED SELECTION: 

EASTON, ELIZABETH 
MIDDLESEX MEMORIAL HOSPITAL 
HARTFORD HOSPITAL 
PATTERSON, IRVING 
IRVINGTON, JAMES 
DAVIDS, JOHN 
BROWN, ALFRED 
BANKS, SUSAN 
BRIGHAMS, SAMUEL 
JACKSON, CARMEN 
PALMER, DOROTHY 
ST. FRANCIS HOSPITAL 
RIVERVIEW HOSPITAL 
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TABLE XLI-continued 



SMITH, FRANKLIN 



ENTER) SELECT RECORD 



5) NEXT/LAST 



16. Print Queues 

There are two main output facilities available 
through CAS. They are the LOHC (Local Output Hold 
Control) facility and the Text Processing Print Queue. 
(Local Copy is available to print out single screen trans- 
actions or to print out one screen of a multi-screen 
transaction. Local copy is sent to the designated printer 
(without LOHC intervention)). 

As indicated above, the Text Processing function 
provides the means for the selection and completion of 
the majority of the claim ofTice forms and letters. All 
documents are complete coming off the printer. Some 



and any special handling instructions. A Document 
Summary File Print Queue screen (not shown) is also 
provided to give an overview of the documents to be 
printed and filed. Again, documents are listed by group 
and number of documents requested along with any 
special handUng instructions. 

A number of Detail Queue screens (not shown) refor- 
mat the summary information of the Document Sum- 
mary Mail and File Print Queues into detailed columns 
that list: 

1) claim number; 

2) document name; 

3) group; 

TABLE XLII 



DOCUMENT SUMMARY MAIL PRINT QUEUE 



GROUP 



NAME 



BLKSTK 
BLKSTK 
BLKSTK 
LTRHED 
LTRHED 



BLANK STOCK (SHEET FEED) 
BLANK STOCK (SHEET FEED) 
BLANK STOCK (SHEET FEED) 
LETTERHEAD 
LETTERHEAD 
LETTERHEAD 



1) PRINTED DOCUMENTS 



documents are ready for mailing immediately after 4) request date; and 
printing. However, multipart forms need to be torn 5) user ID. 

apart and distributed. Depending upon office structure, 40 For example, the Detail Queue by Claim Family screen 
an output operator generally pulls all text processing shown in Table XLIII, displays all requested documents 
output and mails or completes the "processing" of the for the applicable claim family. The documents dis- 
output. played are listed in claim number order. 

Depending on the form, a document request is also The Local Output Hold Control facility (LOHC) is 
sent to a mail print queue or a file print queue or both. 45 an electronic storage facility designed to hold informa- 
After documents are sent to one or both of these print tion which is waiting to be printed^as a result of; 



queues, the request for document printout is initiated, as 
described above, via the print queue facility. A Docu- 
ment Summary Mail Print Queue screen, shown in 



input to the local database. There are a number of 
types of output printed from LOHC including Print 
Transactions, Transaction Logging and a 

TABLE XLIII 



DETAIL QUEUE BY CLAIM FAMILY 



CLM NUMBER 



DOCUMENT 



GROUP REQ DATE UID 



_ 033 00110 MEDICAL REQUEST TO DOCTOR 

_ 033 00110 MEDICAL REQUEST TO DOCTOR 

_ 033 00112 REQUEST FOR POLICE REPORT 

_ 033 01112 DEDUCTIBLE RECEIVED LTR PRATE 

_ 033 00112 DEDUCTIBLE RECEIVED LTR PRATE 



LTRHED 
LTRHED 
LTRHED 



07/08/87 
07/08/87 
07/08/87 
07/08/87 
07/08/87 



Table XLII, provides an overview of the documents to 
be printed and mailed. Documents are hsted by group 
(paper type) with the number of documents requested 



variety of system reports. The Print Transaction, when 
requested, generates a hard copy of selected processed 
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(completed), multi-screen CAS transaction screens. mor 
This may be used, for instance, when a claim is to be 
transferred to another office for completion or partial 
investigation. Transaction Logging captures and sends 
every screen of most CAS transactions to LOHC to 
print into hard copy in the event of system failure. If a 
daily system backup is run, the Transaction Logging 
data is deleted. A number of system and database re- 
ports are also printed which flow through the LOHC. 
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more fields can be entered in the Status Option Menu 
(e.g. entering a date and form number will display the 
status of all reports created on the specified date for 
printing on the specified paper, entering no date will 
5 default to all reports queued for that user). A Default 
Status screen, shown in Table XLIV, displays all re- 
ports in ascending order by group and secondarily, in 
descending order by date within the group. An operator 
delete or print all sent or unsent pages of a report by 



Such reports include processing error reports, reassign- 10 positioning the cursor on the left side of the desired 



It reports, overnight system reports, etc. 
All the reports reflect a system generated creation 
date. The creation date is the date the report originally 
entered the print queue (loaded in LOHC). For On- 
Line reports, this is the date the information to produce 15 Table XLV. 

TABLE XLIV 



report and pressing the appropriate function key. In 
addition, an operator can change the printer destination, 
the number of copies or select specific pages to be 
printed by using the Print With Options menu shown in 



lcx;al output hold control - default 



REPORT 



(REPORT) 



HOSTHCPY 

HOSTHCPY 

HOSTHCPY 

HOSTHCPY 

HOSTHCPY 

HOSTHCPY 

HOSTHCPY 

HOSTHCPY 

HOSTHCPY 

HOSTHCPY 

HOSTHCPY 

LOHC 

LOHC 

PRTTRANS 

PRTTRANS 



HHC LPT AUTO 
HHC LPT AUTO 
HHC LPT AUTO 
HHC LPT AUTO 
HHC LPT AUTO 
HHC LPT AUTO 
HHC LPTX WC 
HHC LPTX WC 
HHC LPTX WC 
HHC PAYMENTS 
HHC PAYMENTS 
SCTY BY RPT 
SCTY BY USER 
PTRS LPT AUT 
PTRS LPT AUT 



(HCLPAUTO) 
(HCLPAUTO) 
(HCLPAUTO) 
(HCLPAUTO) 
(HCLPAUTO) 
(HCLPAUTO) 
(HCLPWORK) 
(HCLPWORK) 
(HCLPWORK) 
(HCPA ) 
(HCPA ) 
(LOHCRPT ) 
(LOHCUID ) 
(PTLPAUTO) 
(PTLPAUTO) 



06/29/89 
07/01/89 
07/02/89 
07/05/89 
07/06/89 

07/02/89 
07/06/89 
07/07/89 



0002 0000 



0004 0000 



the report was input. For Off-Line reports, this is the 
date following overnight processing. 

AH reports are stored in the LOHC facility until they 
ar printed. Once loaded to LOHC, they have a prede- 
termined retention period. After the retention period. 



17. Payments 

Payments are one end result of the processing of 
claims. The entire investigation (adjustment) process 
and the 

TABLE XLV 



LOCAL OUTPUT HOLD CONTROL 

PRINT WITH OPTIONS MENU 
GROUP REPORT (REPORT) CREATED FORM PAGES SENT PTR 

TRXLOG TRANS LOG PAYMENTS TLPA 07/09/87 000 0002 MM C~ 

NEW PRINTER: _ 

# OF COPIES: 

PRINT PAGE RANGE FROM TO 



13) PRINT ALL 15) PRINT SENT 16) PREVMENU 32) TOP MENU 

14) PRINT UNSENT 



an automatic purge occurs and reports that have been 
sent but not printed will no longer be available. 

A Status Option Menu (not shown) is used to select 65 
reports to be displayed. The reports are then displayed 
in accordance with the specific field requested (such as 
date, form number, group or report number). One or 



corresponding documentation is all to determine what, 
if any, payment is owed to a claimant. Payments can be 
repetitive (the same payment for a predetermined per- 
iod of time), multiple and varying, or single sum. Each 
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payment is treated slightly differently by the CAS sys- 
tem and processing varies depending on a claim's status 
(i.e. open or closed) at the time of the payment. 

A different work flow occurs depending on the han- 
dler's selection of the type of payment transaction (i.e. 
close, partial, reopen/close) and the method of issue (i.e. 
machine, manual, repetitive). To choose a claim upon 
which a payment is to be made, a Claim List screen, 
shown in Table XLVI, is provided. This screen displays 
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to reopen a closed claim, issue a check and close the 
claim again. The close Payment Transaction screen 
from which this transaction is undertaken, is shown in 
Table L. 

Frequently, partial payments are made on claims. 
These partial payments are used to compensate a claim- 
ant for only a verified portion of a claim. The Partial 
Payment Transaction screen is provided to record and- 
e partial payments on open claims. The claim 



the claim family and is prefilled, listing the mam claim 10 number is prefilled on the s( 



n which 



number, followed by any companion claim numbers. 
Alternatively, a claim upon which payment is to be 
made, can be chosen through the Select Claim screen 
shown in Table XLVII. 

Once the claim is chosen, a Payment Control screen, 
shown in Table XLVIII is accessed. This screen is used 
to advise the system of the type of payment, the method 
of issue, the check amount, the nature of the payment, 
the payee and the person to whom the check should be 
mailed. Additional information including the claim 
number and the authorizer's initial are prefilled from 
previously entered data. If the payment is to receive 
special handling (e.g. attachment required, return to 
requestor, etc.), it may be indicated on the Payment 
Control screen. 

Manual and Machine Issue Payment screens are pro- 
vided which are nearly identical. However, the Ma- 
chine Issue screen does not include the policy number, 
check number and check digit fields found on the Man- 
ual Issue screen. The Payment-Machine Issue 
shown in Table XLIX. 
TABLE XLVI 

PAYMENT LIST CLAIM SCREEN 
PLEASE SELECT FROM THE LIST OF CLAIMS: 

KEY 

OFFICE CLAIM WIP 

CODE SYMBOL NUMBER INDICATOR 



TABLE XLVII 

PAYMENT SELECT CLAIM SCREEN 



ENTER CLAIM NUMBER _ 



ENTER) SELECT CLM 16) HELP 16) RETURN 

is shown in Table LI. 
' When "repetitive" is selected in the 'Method of Issue' 
field of the Payment Control screen, the Payment- 
Machine Issue screen displays for completion. This is 
because all repetitive payments are machine issued. The 
Repetitive Payment Transaction screen is normally 
is 30 accessed following the completion of the Machine Issue 
and Partial Payment screens. 



00047 
00048 
00049 



ENTER) SELECT CLM 4) PREV/FIRST 18) HELP 16) RETURN 
5) NEXT/LAST 23) LC 



TABLE XLVIII 



PAYMENT CONTROL SCREEN 



CLM NUM: 027 K AP 00002 

TYPE OF PAYMENT: CLOSE: 
METHOD OF ISSUE: MACHINE; 

CHECK AMT: 

PAYEE SAME AS: INSD: CLMT: 

MAIL TO: PAYEE: 
IF OTHER ENTER: NAME: 
STREET: 
CITY: 



AI: FRD 

PARTIAL: REOPEN/CLOSE: 
MANUAL; REPETITIVE: 

NATURE OF PAY; 

INSD/LOSS PAYEE; DIR; OTHER: 

AGENT: 

ST: ZIP: 



TABLE XLVIII-continued 



LOCAL ONLY: 



ENTER) UPDATE 



23) LC 



A Repetitive Payment Schedule Information screen 
is used to advise the system of the number of repetitive 
payments, frequency of issuance (i.e. weekly, bi-weekly 
or monthly) and the date the payments will begin. The 
claim number, authorizer's initials, check amount and 
nature of payment will be prefiUed on this screen, 
which is shown in Table LII. 

A Repetitive Payment Schedule screen (not shown), 
which normally follows the Repetitive Payment Sched- 
ule Information screen, is prefiUed when it displays. 
This screen lists the payments by their respective date 
of issue (automatically 

TABLE XLIX 



TABLE L-continued 



15 A Payment-Route/Process screen is typically the 
final screen in a Payment Transaction. This screen is 
shown below in Table LIII. The Payment-Route/Proc- 
ess screen is used to "process" the Payment Transaction 
or to route the unprocessed payment transaction to 

20 another staff member (e.g. a supervisor) for review. 



PAYMENT - MANUAL ISSUE 

CLM NUM: 027 AP 00002 POL NUM; 02 MVP 1 10355 LOSS DATE; 06/13/88 

INSD NAME: BROWN, JANE 

CLMT NAME: GOVERNALI JOSEPH CLMT STATUS: 

CHECK NUM: 0000000000 ID: IN LIEU CHK NUM: 00000 



I: GOVERNALI, JOSEPH 



AMT: 
AMT: 
AMT: 
AMT: 



ENTER) UPDATE 



calculated form the information input through the 45 
Repetetive Payment Schedule Information screen) 
along with the nature of the payment. This schedule 
should be reviewed by the operator to confirm that the 
prefilled information is correct. If the schedule needs to 
be revised, screens for adding, deleting or modifying 50 
the repetitive payment schedule are available. 
TABLE L 

TRANSACTION 



CLM NUM: 027 AP 00002 



DESTROY DATE: 



CLM ACTION CODE: 
SUIT RESULT CODE: 
COLL SOURCE/TOTAL LOSS IND: 

LOSS PAID: 
ALLOC EXP PAID: 
SUBRO EXP PAID: 
SALVAGE EXP PAID: 
REFUND EXP. PAID: 



When a payment transaction is "processed", the system 
is advised to accept the transaction and to proceed with 
the necessary steps to print the check. If a claim han- 
dler's authority is exceeded by the amount of the pay- 
ment, it is necessary for a supervisor to review the pay- 
ment transaction before it is processed. Thus, the rout- 
ing of the unprocessed payment transaction to a super- 
visor insures that the necesseiry authority will be 
cured prior to the printing of the check. If a handler 
attempts to process a check for more than his autho- 
rized amount, an alert message is generated and the 
transaction is automatically routed to a supervisor. (The 
handler's authorization amount is obtained by interac- 
tion with the Staff Tables.) 

TABLE LI 

PARTIAL PAYMENT TRANSACTION 



CLM NUM: 027 K AP 00002 



CLM ACTION CODE: 
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TABLE Ll-continued 
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TABLE Llll-continued 



NEXT TRANS: 



ENTER) ROUTE 2) 
18) HELP 16) 



18. Windowing 

J . , . . • XL i.-r» Referrals and Investigative Instructions are examples of 

Incorporated into the present system IS the capability ^vtiwiiaioau e „,„„v™r;iK^^ 

. u 1 J X \u f . „ „, information which will form a queue m a user s mailbox. 

rs^gSSir^^^^^^^^^^^^ IrcrdrndoTing" . ^ M^box Menu scree, shown Table LIV p^- 

(In a preferred embodiment ofthe present invention tWs 15 the user with an md.cation of the tyP^^ °f ' 

function is provided as a Wang © utility, but it is avail- ^^^^^im, if any (e.g_ assignments referra s 

able through many other vendoTs.) °' ^'«rt^>- ""^^ can access the vari- 

auit uuwueii i.ia.y ouiivi »,uuu / messagcs and display summary listings of assigned 

Once an operator is logged on to the system, he can ^ ' ^ 
"window" to another screen on the same terminal. This 

is accomplished by pressing a combination of two keys 20 TABLE LIV 

at the same time. The combination of the 'Shift' key and mailbox menu 

the 'Next' key move the operator between the various 

windows. 

TABLE LII 

REPETITIVE PAYMENT SCHEDULE INFORMATION 



CLM NUM: 027 C 40987 
CLM AMT: 200.00 
NAT. OF PAYM: TEMPORARY COMPENSATION— 



NUMBER OF PAYMENTS: ( 
FREQUENCY OF PAYMENTS: 
REPETITIVE PAYM START DATE; 



ENTER) GEN REP PAYM SCHED 18) HELP 16) RETURN 23) LC 32) CANCEL 



The system treats each window as a separate termi- 
nal. As such, it is necessary to log on and log off every 
window in order to access and depart from the system. 45 
This function permits an operator to perform multiple 
transactions at the same time including: viewing the 
Directory Tables while inputting Text fields; answering 
a telephone inquiry while inputting notices of losses; 
and interfacing with the Host while performing any 50 
other function. 

19. Mailboxes 
Mailboxes are the equivalent of a "message waiting" 
function. "Alert" messages, Loss Processing Referrals, 55 
Payment 

TABLE LIII 

PAYMENT - ROUTE/PROCESS 



MESSAGES 
WAITING 



1) Assignment Mailbox X 

2) Referral Mailbox X 

3) Alert Message Mailbox X 

4) Wang Office 
16) Return 

-OR- 

Supply a new Trans Code and press ENTER: 



The selection of the Assignment Mailbox accesses an 
Assignment Mailbox screen which shows claims that 
have been assigned to a claim handler. This screen, 
shown in Table LV, displays assignments, in summary 
form, in chronological order. Bach assignment can be 
reviewed by the claim handler by positioning the cursor 
next to the assignment entry and pressing 'Enter'. When 
an assignment has been reviewed a 'Y' appears in a 
'Reviewed' field which indicates that item can be de- 
leted automatically at the end of the day by the system. 



CLM NUM: 027 AP 00002 

ROUTE TO INITIALS: 



TABLE LV 



ASSIGNMENT MAILBOX 
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TABLE LV-continued 



ASSIGNED 

TYPE INSURED NAME BY 
REVIEWED DATE TIME CLAIM NUMBER CLAIMANT NAME FMD 

LPTX CRANE CONSTRUCTION CO. 
N 12/09/87 11:06:05.36 023 C 00139 BILL SMITH 



POSITION CURSOR IN FRONT OF ITEM TO BE REVIEWED AND PRESS ENTER 
17) NT 

23) LC 16) RETURN 



A Referral Mailbox screen, shown in Table LVI, 20 TABLE LVII-continued 

contains: payment referrals and LPT referrals (new ^ 

LPTs, HTC Received, Add Companion and Local 5) staff^Table 
Only). These transactions appear in the above order and incomplete forms 

with each set of items corresponding to a particular 
transaction sorted in chronological order. As with as- 2 
signments, each referral can be selectively reviewed. 
After review, the item entry will be deleted (unless the 

operator chooses to maintain the entry for additional -OR- 
review. This can be done by selecting the appropriate 

function key). SUPPLY A NEW TRANS code AND PRESS ENTER: 

TABLE LVI 



type/ insured name routed 

reviewed date time claim number claimant name by 

i inst buffalo oil company, inc pma 

12/10/87 07:42:57.16 023 c 00053 charlie brown 



POSITION CURSOR IN FRONT OF ITEM TO BE REVIEWED AND PRESS ENTER 



4) PREV/FIRST 9) SELECT TYPE 17) NT 

5) NEXT/LAST 1 1) CHANGE INITIALS 18) HELP 
8) DELETE 23) LC 



An Alert Message Mailbox screen, shown in Table 
LVII, may also be accessed from the Mailbox Menu 
screen. This menu (mailbox) is only available to staff 
members who are in a supervisory position. This mail- 
box provides access to alerts which have been gener- 
ated including: LPT Referral/Assignment Delay, Au- 55 
thority Level Exceeded and Diary and Staff Table 
Alert Messages. 

TABLE LVII 



ALERT MESSAGE MAILBOX 60 
FOR RDC 

PRESS THE APPROPRIATE PF KEY AS LISTED BELOW 

MESSAGES 
WAITING ,5 



1) LPT REFERRAL/ASSIGNMENT DELAY X 

2) AUTHORITY LEVEL EXCEEDED X 

3) DIARY X 



NEXT TRANS: 



A provision also exists within the mailbox function to 
send intraoffice electronic mail (primarily administra- 
tive memos and the like). This function is preferably 
accessed through the "Wang Office" automation pro- 
gram which is available when Wang (R) brand comput- 
ers and peripherals are used throughout a claims office. 
This function is not, however, limited to Wang (g) brand 
equipment. One of skill in the art would be able to pro- 
vide such a feature using any comparable hardware. 

20. The Diary Function 
The ability to "diary" a claim which requires subse- 
quent activity is an integral facet of the loss adjustment 
process. The diary is a personal diary, determined by 
the operator's User ID. It has the capability to record a 
specified date for action on a claim, to display that claim 
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at the appropriate time and to "rediary" as needed. 
When an LPT is processed, the system automatically 
sets the diary date for the supervisor according to Staff 
Table parameters. This date is predetermined based on 
the type of claim and the experience level of the handler 5 
but can be overridden if necessary. 

The diary, is formatted by staff member, for each day 
of the year on which a claim has been placed on the 
diary. A Diary Listing screen, shown in Table LVIH, 
displays all claims diaried for a specified day. The date 10 
displayed defaults to the current date, but future diary 
dates can also be accessed. 

TABLE LVIII 



INSURED NAME CLAIM NUMBER 

CLAIMANT NAME LOSS DATE 

FILE 023 AC 0001 

SMITH, JOHN 02/02/89 FILE 



The diary history, displayed on a Diary History 
screen (not shown) lists all dates set by a supervisor for 
a particular claim (past, present and future). The diary 
history is primarily used as a quality control review by 
management. 

A Diary Function screen, shown in Table LIX, per- 
mits: diary creation; deletion; rediary; alternate diary; 
and access to a diary history. The Diary Function 
screen can be used to display all dates diaried for a 
particular claim in chronological order. A record is 
maintained for any claim for which at least one diary 
date existed. 

Diary dates may be set by any Staff member for a 
particular claim. However, only the initial supervisor 
diary dates are set automatically. For instance, a claim 
handler may wish to set personal diary dates to remind 
him to do certain things. In such cases, it is usually 
helpful to provide comments with the diary date. Com- 
ments are entered through the Activity Log function 
and are accessible when the diary date(s) is displayed. 

TABLE LIX 
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generated when the maximum number of diary entries 
allowed for an individual on a per day basis (set through 
the Staff Tables) has been exceeded, when a handler 
allows his diary to "roll over" more than a set number 
of claims (diary dates automatically "roll over" to the 
next day when they are not accessed or acted upon by 
the handler), when an attempt is made to diary a day 
that has been identified as a vacation or non-working 
day (set through the Staff Tables), or when an attempt 
is made to diary a date that is more than six months in 
the future. 

21. Ad Hoc Reporting 

The Ad Hoc Reporting function is a standard soft- 
ware database query. It is used to extract any local 
database information which is desired. As with most 
software database queries the output from the extrac- 
tion can be arranged in any manner. 

A number of preformatted reports or queries are 
available to all claims offices. These include: Duplicate 
Payment Reports, Claim Handler Outstanding Claim 
Reports and Activity Log Disaster Recovery reports. 
An example of a custom local claims office report is a 
Weekly Claim Input Summary. This report totals the 
number of claims input for a given week. It can be done 
office wide and/or by line of business. Essentially, the 
Ad Hoc Reporting function can extract and format any 
system database information into a report. 

22. Local Data 

The Local Data function provides an individual 
claim office with the ability to define and record local 
specific data through generic definitions maintained by 
the CAS system. It permits a local claims office to name 
the input elements (prompts) as they wish them to ap- 
pear on a screen and to capture these elements at logical 
points within the CAS system workflow. 

A Local Data Label Maintenance screen (not shown) 
is provided which functions as a menu to permit an 
operator (usually a supervisor with a very high security 
level) to choose specific input fields (i.e. policy, claim- 
ant, claim or payment information) to establish. By way 
of example, a Local Claim Information Labels screen is 
shown in Table LX. This screen permits the operator to 
choose screen labels for preformatted generic input 
fields. The preformatted generic input fields include a 



DIARY FUNCTION 



CLAIM NUMBER: 023 C 00002 
INSURED NAME: STRADLIN, IZZY 
CLAIMANT NAME: BAILEY, BILL 
LOSS DATE: 03/03/89 

DIARY REASON RI 

DATE BY FOR 

03/15/89 LAE FI 

05/02/89 RJM A< 



SUPV.: ALB 

DESCRIPTION 
SIDE CLAIM REP 
OE CLAIM REP 



4)PREV/F1RST 6) ADD 8) DELETE 14) ACTIVITY LOG 17) NT 

16) RETURN 5) NEXT/LAST 7) SELECT 15) DIARY LISTING 18) HELP 

23) LC 11) HISTORY 22) FAMILY REDIARY 

ENTER TO CONFIRM OR PF 1 TO RE-SELECT. ^ 20020 



Diary alert messages, mentioned above, are returned 
to the operator's screen as well as being routed to a number of 10 byte numeric fields, 2 byte character 
supervisor's message queue (mailbox). Such alerts are fields, 30 byte character fields and 6 byte date fields. 
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LOCAL CLAIM 



SCREEN LABELS 



liTTEST INC LOSS 

2: TP PAID 

3: TP EST INC LOSS 

4: TP PAID 

:5: MEDICAL PD 

16: HOSPITAL PAID 



(NUMBER 10) C1LMISC(1THRU6)PAID 

(NUMBER 10) C12: CLMT'S ATTY EST INC 

(NUMBER 10) C13: CLMT S ATTY PAID 

(NUMBER 10) C14: RECOVERY AMOUNT 
(NUMBER 10) 
(NUMBER 10) 



(CHAR 30) 
(CHAR 30) 
(CHAR 30) 
(CHAR 30) 



C8: DRUGS PAID 

C9: MED TRANS. PAID 

10: MEDICAL EST INC 



(CHAR 2) 
(CHAR 2) 
(CHAR 2) 
(CHAR 2) 
(CHAR 2) 
(CHAR 2) 

(CHAR 30) 
(CHAR 30) 
(CHAR 30) 



1: DATE CLMT 1ST CONTAC (DATE) 

2: DATE 1ST COMP PAYMENT (DATE) 

3: DATE COMP STOP/SUSP (DATE) 

4: (DATE) 

i5: (DATE) 

5; (DATE) 



Once the desired number of generic input fields have 
been given specific labels (not all the generic fields have 
to be used) they are arranged into an input format on a 
Local Claim Information screen such as that shown in 
Table LXI. 

TABLE LXI 



cific information. In a law office, each case that is re- 
ceived is recorded through the Initial Input Transaction 
(IIT). The matter name and type as well as the expected 
cost, etc. are input through the IIT. By way of example, 
for a trademark application, the particular trademark, 



LOCAL CLAIM INFORMATION 



CLAIM NUMBER: C I 



POL NO: 02 WB 125487 



TT EST INC LOSS 
TT EST INC LOSS 
MEDICAL (PHYS FEE) PD 



TTPAID 
TP PAID 
HOSPITAL PAID 



DRUGS PAID 
MED TRANSPORTN PAID 
MEDICAL EST INC LOSS 
MISC (1 THRU 6) PAID 
CLMTS ATTY EST INC 
CLMTS ATTY PAID 
RECOVERY A 



DATE 1ST COMP PAYMENT _ 



ENTER) MODIFY 



Information input through the Local Information 
screen(s) is maintained on local databases only. It is not 
communicated to the Host. The purpose of this function 
is to capture data necessary to comply with local filing 
requirements and other specific local needs. Other dedi- 
cated functions, enumerated above, are designed to 
capture information transferred to and used by the 
Host. 

23. Work Management System 
As indicated previously the present invention is a 
system and method for substantially automating work 
management. While reference has been made to a claim 
processing system, numerous other applications will 
occur to those of skill in the art. 

In another preferred embodiment of the present in- 
vention, the work activities of attorneys in a law office 
are managed through the present system and method. 

The Initial Input Transaction (equivalent to the LPT) 
generically provides a facility for recording case spe- 
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its goods and the date of first use are all recorded 
through the IIT. 

The Work Source Index (equivalent to the Policy 
Index) generically provides an accessible database of 

55 work source information. In a law office, the Work 
Source Index (WSI) is maintained as a cUent database. 
Thus, when an IIT is input for an existing client, the 
basic client information is extracted from the WSI and 
prefiUs some of the IIT fields. This is done by inputting 

60 the client number through a WSI screen. 

The Staff Table function generically provides a facil- 
ity for storing information relevant to office personnel. 
Specifically, in a law office, the Staff Tables are used to 
maintain authority levels for access to certain functions 

65 (e.g. billing, docketing, etc.), to track vacation sched- 
ules, to indicate experience levels, to indicate billing 
rate, to indicate areas of expertise, to record Patent 
Office registration numbers, to set overall caseload 
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limits and daily diary or due date limits, to indicate a the like) and billing statements. The openings and clos- 

supervising attorney, etc. ings of letters, as well as the openings and closings of 

The Diary function generically provides a means for trademark/patent applications and amendments are also 

prioritizing work and for scheduling various tasks. In a automatically generated. The intervening text is input 

law office, the diary is used to docket legal due dates, to 5 as with any other word processing package, 

schedule daily meetings, to set business deadlines and to The Directory Tables function generically provides a 

maintain and report certain attorney specific date infor- facility for storing names, addresses and other pertinent 

mation (e.g. the meeting of business deadlines, the num- information of individuals/services. In a law office the 

ber of times diary entries rollover, the number of events Directory Tables function is used to maintain clients' 

diaried for a single day or time period, etc.). 10 names and addresses as well as the names and addresses 

The Activity Log function generically maintains a of courts, process servers, expert witnesses court re- 
record of key activities involved in the processing of porters, etc. 

work items. In a law office the Activity Log is a very The Info Search function generically provides a facil- 
important tool for tracking activity on a case and activ- ity to search for information resident on local databases, 
ity undertaken for a particular client. In practice the 15 In a law office the Info Search function is used to 
Log can be employed on two separate levels. The first quickly provide clients with status reports without at- 
level permits simply the tracking of important activities tomey intervention, to locate case numbers, to deter- 
which occur in handling a case (e.g. the receipt of an mine time billed to a case, etc. 
Office Action, a telephone conference with an Exam- The Local Data function generically provides a facil- 
iner, the mailing of an amendment, etc.). On the second 20 ity for customization of data recordation and output at 
level, the Log is used to track attorney billing. In such . the local level. In a law office the local data function is 
cases an attorney accesses the log for a particular client used for a variety of things including statistical tracking 
and the specific matter and inputs a description of the of client locations, categories of work, etc. However, 
work done and the time spent. This information is then local data can be used for virtually any database man- 
directly fed into an automatic billing function (corre- 25 agement needs. 

spending to the CAS payment function). The Help function, the Print Queue Management 

The generation of Alert Messages generically pro- functions, the Data Carry facility and the various 

vides for the routing of such messages automatically to Change functions (e.g. Control Change, Element 

appropriate staff members upon the breach of some Change, etc.) all perform the same tasks in generic and 

predetermined criteria. In a law office, such messages 30 law office environments. These functions all augment 

are provided when too much time is spent on a case, the use of the specific work processing functions, 

when deadlines are missed, when system security locks While reference has been made to specific hardware, 

out an attempted entry, when a deadline is assigned software and functional elements, these are meant as 

during a scheduled vacation, etc. illustrative only and one of skill in the art may alter such 

The Mailbox function generically provides a facility 35 elements without departing from the spirit and intent of 

for referring work tasks and receiving alert messages. In the present invention, 

a law office cases are assigned with notification placed What is claimed is: 

in attorneys' mailboxes. The cases, and work generated 1. A work management system comprising: process- 
thereon (e.g. a brief, a patent application, etc.), are also ing means, including a data bank into which data is 
routed for review and revision to other attorneys. 40 written and from which data is read, said data bank 

The Caseload Monitoring function generically pro- storing information regarding an initial transaction, 

vides a facility to track and report the workload of the work source information, office staff information, pol- 

staff. In a law office each attorney's caseload is moni- icy information, information regarding dates of impor- 

tored to insure even distribution. Further, with this tance, in formation regarding work processing activi- 

function it is possible to monitor an attorney's progress 45 ties, staff case load information, and predetermined text 

on specific types of cases. data for preparing documents, the data bank including 

The Reassignment function generically provides a staff table means for storing, retrieving, displaying and 
facility to move work from one staff member to an- modifying information about staff members who access 
other. In a law office one or more cases can be easily the system, wherein said stored information includes: 
reassigned to another attorney. The need for reassign- 50 name, user ID, job title, supervisor, experience level, 
ment frequently occurs when an attorney leaves or cost rate, diary rollover limit, scheduled vacation, pay- 
when a case evolves to a point where a higher level of ment authority, and staff functional and processing 
expertise is needed. authority levels; at least one terminal means for commu- 

Automated numbering is of particular value in a law nicating with said processing means and operable by at 

office. Each case must be identified with a client and 55 least one operator to produce requests and to enter 

matter numbers for easy reference. As such, the system information and/or retrieve information for writing 

provides such numbers automatically without worry of and/or reading from said data bank; display means for 

duplication. Moreover, with the present system and displaying information that is entered and retrieved; 

method there is no need to re-record the numbers for first merging means operatively interacting with said 
billing purposes. 60 processing means for reading out from said data bank 

Text Processing generically provides for the genera- selected information regarding work processing activi- 
tion of Preformatted form letters. It includes system ties and selected office staff information and merging 
controlled extraction of applicable information from said read out work processing activities information and 
local databases to prefill blank fields, automatic Activ- said read out office staff information to compile an 
ity Log recording and paper type and copy manage- 65 activity log listing key work activities and a staff mem- 
ment. In a law office Text processing is used to automat- ber associated with those activities; case stmimary 
ically generate forms for legal filings (e.g. declarations, means for automatically summarizing said initial trans- 
powers of attorney, etc.), letters (reporting letters and action information; routing means for routing transac- 
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tion information to a staff member for processing in e) the phonetic equivalent of a customer's last name; 

response to input through one of said terminal means; or 

and staff member electronic mailbox means for receiv- f) date of initial transaction. 

ing said initial transaction summary and other electronic 9. A system according to claim 1, further comprising 
messages; assignment means for assigning a case to a 5 interactive, online help means for providing assistance 
particular staff member for processing in response to in using the work processing system, 
input through one of said terminal means; reassignment 10. A system according to claim 1, further comprising 
means for reassigning cases from a particular staff mem- status change means for electronically reopening, par- 
ber to another staff member for processing, diary means tially reopening or closing the processing of a case, 
for automatically and manually setting, storing and 10 H- A system according to claim 1, further comprising 
displaying dates for various activities associated with automatic numbering means to automatically assign a 
the processing of a case including means for manually number to each new case for which processing is under- 
overriding automatically set diary dates; activity log taken. 

means for automatically recording information about 12. A system according to claim 1, further compnsmg 
transactions undertaken through the system in the pro- 55 security means for limiting access to the system to only 
cessing of a case and for manually recording informa- those individuals with preselected authorization codes, 
tion and comments about other activities in the process- 13. A system according to claim 1, further comprising 
ing of a case including means for selectively displaying windowing means for accessmg and processing a plural- 
said recorded information and comments on said dis- ity of different cases simultaneously at one terminal 
play means; inquiry means for selectively retrieving and means. 

displaying transaction information in response to input M- A system according to claim 1, further compnsmg 

of at least one case number through one of said terminal print queue management means for controlhng the 

means; system controller means for controlling an oper- printing pnonty of documents, 

ator's movements within the system, wherein said sys- 15. A system according to claim 1, wherem said data 

tern controller means verifies the availability of each „ bank stores mformation regarding customers, 

requested function during a system session and verifies " . A system accordmg to claim 15, further compns- 

said operator's authority to access a system function '"S second mergmg means operatively interacting with 

prior to permitting such access; and security means said first processing means for reading out from said 

comprising security level means for selectively limiting data bank mitial transaction information and readmg out 

access to certain predetermined functions of the system ,„ customer mfonnat.on and merging said read out mitral 

in accordance with a preset security level associated 3° transaction information and said read out r„«nn,Pr 



with each authorization code. mformation to conipile an mdividualized work process- 

2. A system according to claim 1, further comprising '"g record for each case to be processed^ 

second merging means operatively interacting with said »]: ^ system accordmg to claim 1, further compnsmg 

processing means for reaching out from said data bank modification means for altenng smd infonnation regard- 

Llected infonnation and predetennined text data and ^5 mg an mit.al transaction after said mfonnation has been 

merging said read out information and said read out text storea m saia aata oanK. ;„f„, 

J . ~ * -1 i- 1 J .1 . 1 J . J 18. A system according to claim 1, wherem said infor- 

data to compile final documents tailored to a case; and ^^^.^^ .^^^ transaction is electronically 

pnnt means coupled to said processing means for pnnt- {-^st processing means from a remote 

mg said documents. ^ , , , , . . 40 location and stored in said data bank. 

3. A system accordmg to claim 2, further compnsmg ^ ^ ^ according to claim 1, further comprising 
du-ectory means for selectively storing retneving and ^^^^ processing means for creating, displaying, modify- 
displaymg mfonnation relatmg to individuals to be con- j„g ^ ^ ^^^^^g customized documents having at least 
tacted during work processing. , ^ . one blank input field, wherein said blank input fields are 

4. A system accordmg to claim 3, wherein infonna- ^^^^ f^r use by said second merging means to merge 
tion stored by said directory means is automatically ^^.^ infonnation and customized document 
selected by category and displayed if said second merge ^ata in accordance with said blank input field codes to 
means is unable to compile a final document because of compile final documents. 

missing information. 20. A system according to claim 19, wherein said 

5. A system according to claim 1, further comprising compiled final documents are transmitted to print queue 
mailbox view means for displaying electronic messages 50 means to permit review of said compiled documents and 
on said display means. their characteristics prior to printing. 

6. A system according to claim 1, further comprising 71. A system according to claim 1, further comprising 
alert means for automatically generating and routing an report means for generating and formatting reports 
alert message to a first staff member's electronic mail- based on information stored on said data bank, wherein 
box means when a predetermined criterion is breached 55 g^id reports may comprise sums, summaries and lists of 
by an operator. any of said information stored on said data bank and 

7. A system according to claim 1, further comprising may be formatted in any preferred manner, 
electronic mail means for creating and sending messages 22. A system according to claim 1, further compris- 
from one terminal means to another. ing: a plurality of generic field generators for receiving 

8. A system according to claim 1, further comprising 60 alphanumeric, numeric and date input information pro- 
search means for locating a case file which resulted duced at a terminal means and storing said input infor- 
from the input of said initial transaction information, mation for said generic fields locally in said data bank; 
wherein said search means requires input of at least one label creation means for creating and assigning text 
of the following: labels to said generic fields; and programming means for 

a) a customer number; 65 arranging at least some of said generic fields into at least 

b) a case number; one specialized input screen for display at said terminal 

c) an customer's complete last name; means. 

d) part of a customer's last name; * » * * » 



